Click here to Skip to main content
15,860,943 members
Articles / Operating Systems / Windows

Loosely Couple Your Tests

Rate me:
Please Sign up or sign in to vote.
4.65/5 (15 votes)
16 May 2013CPOL4 min read 35.5K   38   10
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

C#
/// <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

C#
/// <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

C#
/// <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...

C#
/// <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.

C#
/// <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.

C#
/// <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.

C#
/// <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...

C#
/// <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)


Written By
Architect Microsoft
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.

Comments and Discussions

 
GeneralA couple of corrections Pin
JoshuaMcKinney5-Sep-07 16:30
JoshuaMcKinney5-Sep-07 16:30 
GeneralRe: A couple of corrections Pin
Peter Hancock5-Sep-07 22:14
Peter Hancock5-Sep-07 22:14 
GeneralGreat Pin
taras_b5-Sep-07 12:52
taras_b5-Sep-07 12:52 
GeneralGreat Ideas. Great Article Pin
Ben Pritchard5-Sep-07 0:37
Ben Pritchard5-Sep-07 0:37 
GeneralRe: Great Ideas. Great Article Pin
Peter Hancock5-Sep-07 1:12
Peter Hancock5-Sep-07 1:12 
GeneralRe: Great Ideas. Great Article Pin
Ben Pritchard5-Sep-07 2:36
Ben Pritchard5-Sep-07 2:36 
GeneralRelated book Pin
Paul B.4-Sep-07 9:02
Paul B.4-Sep-07 9:02 
GeneralRe: Related book Pin
Peter Hancock13-Sep-07 15:35
Peter Hancock13-Sep-07 15:35 
Questionhow about Pin
Thanks for all the fish29-Aug-07 3:34
Thanks for all the fish29-Aug-07 3:34 
AnswerRe: how about Pin
Peter Hancock29-Aug-07 19:07
Peter Hancock29-Aug-07 19:07 

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

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