Click here to Skip to main content
Click here to Skip to main content

Loosely Couple Your Tests

, 16 May 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
Loosely couple your tests from your implementation to allow your implementation to be refactored, without having to change the tests

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

/// <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 entries 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);
    }
}

Screenshot - Take-1.jpg

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...

/// <summary>
/// Tests.  Note that there is currently no naming scheme - we leave that for 
/// refactoring to find...
/// </summary>
[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.

/// <summary>
/// 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. 
/// </summary>
[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.

/// <summary>
/// Manage overall setups for blog test
/// </summary>
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();
    }
}

/// <summary>
/// Test cases focusing on the normal flow of operations and the successful
/// outcome
/// </summary>
[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;
    }
}

/// <summary>
/// Tests to ensure that only valid data gets posted (Alternative flows)
/// </summary>
[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);
    }
}

Screenshot - Take-2.jpg

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.

/// <summary>
/// Ensure that entries are created with default values
/// </summary>
[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...

/// <summary>
/// Ensure that draft entries can be persisted
/// </summary>
[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);
    }
}

Screenshot - Take-3.jpg

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

  1. Updated example call to remove spurious call to Setup(); Unnecessary as the text fixture will run it.
  2. 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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Peter Hancock
Program Manager Amazon
United States United States
Nutcase triathlete that likes doing long course triathlons. Planning on competing in the Hawaiian Ironman at some stage - in fact - just as soon as I qualify.
Follow on   Twitter   LinkedIn

Comments and Discussions

 
GeneralA couple of corrections PinmemberJoshuaMcKinney5-Sep-07 17:30 
Really good article, and I just have a couple of finicky points:
 
1. In the second example code in part 2 the Setup method will be called twice. Once by the unit test runner and once by the unit test itself
 

public void PostSingleItemIncreasesCount()
{
SetUp(); // should not be called here
...

 
2. You have used ArgumentNullException for places where the actual argument is not null. This should actually be ArgumentOutOfRangeException or perhaps ArgumentException.
GeneralRe: A couple of corrections PinmemberPeter Hancock5-Sep-07 23:14 
GeneralGreat Pinmembertaras_b5-Sep-07 13:52 
GeneralGreat Ideas. Great Article PinmemberBen Pritchard5-Sep-07 1:37 
GeneralRe: Great Ideas. Great Article PinmemberPeter Hancock5-Sep-07 2:12 
GeneralRe: Great Ideas. Great Article PinmemberBen Pritchard5-Sep-07 3:36 
GeneralRelated book PinmemberPaul B.4-Sep-07 10:02 
GeneralRe: Related book PinmemberPeter Hancock13-Sep-07 16:35 
Questionhow about PinmemberThanks for all the fish29-Aug-07 4:34 
AnswerRe: how about PinmemberPeter Hancock29-Aug-07 20:07 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.141223.1 | Last Updated 16 May 2013
Article Copyright 2007 by Peter Hancock
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid