Introduction
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.
The Practice
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
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
[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
[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...
[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 arises - 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.
[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);
}
}
Focusing 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 successful postings, and invalid posting data.
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();
}
}
[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;
}
}
[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 two things to deal with are the default values on creating an entry, and the addition of draft entries to the blog without posting.
[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...
[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.
Conclusion
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 focusing on forcing the code to fit the test structure, but rather, focusing on how the code solves the behavioural requirements of the tests.
Edits
- Updated example call to remove spurious call to
Setup(); Unnecessary as the text fixture will run it. - Changed
ArgumentNullException to ArgumentException in tests for Title and Content as an empty string is not null - but is instead an invalid Argument. Could also have used out of range, but that implies to me a range of values is expected (1 - 100 for example) - thanks to Joshua McKinney for these.
