One of the most common set of tests that I see is the upfront naming of one fixture for one class. The difficulty occurs when later on the classes become refactored into other classes and you're left with fixtures named after classes that no longer exist. Perhaps more insidious though is that by having this coupling, you increase the amount of inertia that must be overcome in order to refactor a class. In order to maintain a perceived consistency, you have to rename the test fixtures. Even worse, many current source code implementations refuse to play happily with renaming of files, so the refactoring tools are less effective, and the resistance to change increases again. By decoupling the tests from the implementation, the tests can stand on their own, and the implementation is free to be refactored as needed.
Consider a very simple implementation of a Blog Engine. The story is as follows...
A blog consists of a number of entries. Each entry must have a title and content. Each entry gets a date created which refers to when the entry was initially drafted, and the date posted which indicates when the entry was published. An entry can be created and added to the blog without being posted - a draft. An entry can be created and immediately posted. An draft can be posted at a later date.
Take 1
A fairly typical implementation would consist of the following fixtures... (after some refactoring)
TestBase.cs
/// <summary>
/// Contains common constants and objects for testing blog and entry classes
/// </summary>
public class TestBase
{
protected Entry _entry;
protected const string _testTitle = "Test Title";
protected const string _testContent = "Test Content";
protected void SetUp()
{
_entry = new Entry();
}
}
EntryFixture.cs
/// <summary>
/// Tests to ensure Entrys are valid and have the correct defaults
/// </summary>
///
[TestFixture]
public class EntryFixture : TestBase
{
[SetUp]
public void SetUpEntryFixture()
{
SetUp();
}
[Test]
public void CanGetAndSetProperties()
{
_entry.Title = _testTitle;
_entry.Content = _testContent;
Assert.AreEqual(_testTitle, _entry.Title);
Assert.AreEqual(_testContent, _entry.Content);
}
[Test]
public void EntryCreatedGetsCreatedDate()
{
Assert.AreEqual(DateTime.Today, _entry.Created);
}
[Test]
public void ValidEntryHasTitleAndContent()
{
_entry.Title = _testTitle;
_entry.Content = _testContent;
Assert.IsTrue(_entry.IsValid);
}
[Test]
public void EntryWithoutTitleIsInvalid()
{
_entry.Content = _testContent;
Assert.IsFalse(_entry.IsValid);
}
[Test]
public void EntryWithoutContentIsInvalid()
{
_entry.Title = _testTitle;
Assert.IsFalse(_entry.IsValid);
}
}
BlogFixture.cs
/// <summary>
/// Provides tests around the behaviour of the blog.
/// </summary>
[TestFixture]
public class BlogFixture : TestBase
{
private Blog _blog;
[SetUp]
public void SetUpBlogFixture()
{
SetUp();
_blog = new Blog();
}
[Test]
public void PostingEntryProvidesPostedDate()
{
_entry.Title = _testTitle;
_entry.Content = _testContent;
_blog.Post(_entry);
Assert.AreEqual(DateTime.Today, _entry.Posted );
}
[Test]
public void PostingEntryIncreasesBlogEntryCount()
{
_entry.Title = _testTitle;
_entry.Content = _testContent;
_blog.Post(_entry);
Assert.AreEqual(1, _blog.Count);
}
[Test]
[ExpectedException(typeof(ArgumentException))]
public void AnInvalidBlogCannotBePosted()
{
Entry entry = new Entry();
_blog.Post(entry);
}
}
This leads to two classes - Entry and Blog. This makes sense of course, and the implementation is quite simple and neat. In short, this path of TDD leads to a successful implementation of Blog and Entry, I can post, get the dates, and have rudimentry validation on my blog.
The downside though is that the reader / business analyst / new developer, that picks up these tests has an increased inertia in changing them. The very name of the test fixtures themselves forces an almost subliminal desire to maintain the current Blog / Entry structure, reducing the flexibility and creativity of the developer.
Take 2.
Same story, but remove any sort of artificial constructs and just add the tests one after the other refactoring mercilessly. I started with the simplest thing I could think of that provided some behaviour...
///
/// Tests. Note that there is currently no naming scheme - we leave that for refactoring to find...
/// [TestFixture]
public class Fixture
{
[Test]
public void PostSingleItemIncreasesCount()
{
Blog.Post("Test Title", "Test Content");
Assert.AreEqual(1, Blog.Count);
}
}
After the addition of the second test, which is to assert that the PostedDate is attached to the Blog, the following information arrises - one - we need an Entry class with which we can populate the blogs Posted with, and two, we can refactor out the setup of both tests into a setup method and give the fixture a readable name. This covers of the requirements of "number of entries" and "contains a posted date" from the story.
///
/// The tests are starting to flesh out - we can now rename things - for instance, the
/// Fixture has now become SuccessfulPosting, and we've extracted the requirements for a successful posting into the setup.
///
[TestFixture]
public class SuccessfulPosting
{
private int _index = 0;
private Blog _blog;
[SetUp]
public void SetUp()
{
_blog = new Blog();
_index = _blog.Post("Test Title", "Test Content");
}
[Test]
public void PostSingleItemIncreasesCount()
{
Assert.AreEqual(1, _blog.Count);
}
[Test]
public void PostSingleItemProvidesPostedDate()
{
Assert.AreEqual(DateTime.Today, ((Entry)_blog.Entries[_index]).Posted);
}
}
Focussing next on invalid entries leads to the extraction of a simpler setup super class which contains methods to instantiate a blog and provide clean entry classes for testing succesful postings, and invalid posting data.
///
/// Manage overall setups for blog test
///
public class TestBase
{
protected Entry _cleanEntry;
protected Blog _blog;
protected void Prepare()
{
_cleanEntry = GetCleanEntry();
_blog = GetTheBlog();
}
public static Blog GetTheBlog()
{
return new Blog();
}
public static Entry GetCleanEntry()
{
return new Entry();
}
}
///
/// Test cases focussing on the normal flow of operations and the successful outcome
///
[TestFixture]
public class SuccessfulPosting : TestBase
{
private const string testTitle = "Test Title";
private const string testContent = "Test Content";
protected Entry _validEntry;
[SetUp]
public void SetUp()
{
Prepare();
_validEntry = GetValidEntry();
_blog.Post(_validEntry);
}
[Test]
public void IsContainedInBlog()
{
Assert.Contains(_validEntry, _blog.Entries);
}
[Test]
public void PopulatesDatePosted()
{
Assert.AreEqual(DateTime.Today.Date, ((Entry) _blog.Entries[0]).PostedDate);
}
public static Entry GetValidEntry()
{
Entry entry = GetCleanEntry();
entry.Title = testTitle;
entry.Content = testContent;
return entry;
}
}
///
/// Tests to ensure that only valid data gets posted (Alternative flows)
///
[TestFixture]
public class PostingValidation : TestBase
{
[SetUp]
public void SetUp()
{
Prepare();
}
[Test]
[ExpectedException(typeof(ArgumentException))]
public void FailsIfTitleNotPopulated()
{
_cleanEntry.Content = _testContent;
_blog.Post(_cleanEntry);
}
[Test]
[ExpectedException(typeof(ArgumentException))]
public void FailsIfContentNotPopulated()
{
_cleanEntry.Title = _testTitle;
_blog.Post(_cleanEntry);
}
}
Note that this is now inherently more readable. Posting validation rules have been moved and renamed into a group, as have the rules around successful postings. The last thing two things to deal with are the default values on creating an entry, and the addition of draft entries to the blog without posting.
///
/// Ensure that entries are created with default values
///
[TestFixture]
public class EntryDefault : TestBase
{
[SetUp]
public void SetUp()
{
Prepare();
}
[Test]
public void CreatedDateIsToday()
{
Assert.AreEqual(DateTime.Today.Date, _cleanEntry.CreatedDate.Date);
}
}
And finally, the addition of entries as drafts...
///
/// Ensure that draft entries can be persisted
///
[TestFixture]
public class DraftAddition : TestBase
{
[SetUp]
public void SetUp()
{
Prepare();
_blog.Add(_cleanEntry);
}
[Test]
public void IncrementsBlogCount()
{
Assert.AreEqual(1, _blog.Entries.Count);
}
[Test]
public void IsContainedInBlog()
{
Assert.Contains(_cleanEntry, _blog.Entries);
}
}
This now reads almost like a set of business rules...
- DraftAddition.IncrementsBlogCount
- DraftAddition.IsContainedInBlog
- EntryDefault.CreatedDateIsToday
- PostingValidation.FailsIfTitleNotPopulated
- PostingValidation.FailsIfContentNotPopulated
- SuccessfulPosting.IsContainedInBlog
- SuccessfulPosting.PopulatesDatePosted
- SuccessfulPosting.IncrementsBlogCount
The best thing though is that none of the rules or tests are constraining the implementation. The rules stand on their own. Any changes to the implementation through refactoring tools will change the tests, which is a good thing, but they aren't artificially constrained by the tests.
In short - by removing a preconceived structure from the test fixtures you allow a more organic growth of the code as it adapts to new business rules and constraints. Refactoring mercilessly leads to removed duplication, and frequently, the promotion of "TestHelpers" that create valid objects into product code "Factory" objects. The readability of the tests is enhanced, and even non-developers are able to read them. Finally, the tests are less brittle as you are no longer focussing on forcing the code to fit the test structure, but rather, focussing on how the code solves the behavioural requirements of the tests.