What should you test?
time to read 1 min | 185 words

I just found myself writing this:

[Test]
public void When_resolving_using_framework_element_will_create_layout_using_resolver()
{
}

The code that I want to test looks something like this:

public void Register(FrameworkElement frameworkElement)
{
	Register(layoutDeocratorResolver.GetLayoutDecoratorFor(frameworkElement));
}

public void Register(ILayout layout)
{
	if (layouts.ContainsKey(layout.Name))
		throw new DuplicateLayoutException("Layout names must be unique. A layout named '" + 
                                      layout.Name + "' already exists.");
	layouts.Add(layout.Name, layout);
}

The problem that I have here is that it looks like I am trying to specify the mechanics of the code under test, and that is a big mistake. I really should not care how it is doing it. I should care about the results. Therefor, I decided to change the test to:

[Test]
public void When_resolving_using_framework_element_will_add_layout_decorator_for_that_element()
{
}

Now what I am testing is behavior, not mechanics.

Tests that validate the mechanics of the code are brittle, and end up as testing shackles.

0 comments
Tags:

Related posts that you may find interesting:

10 Aug 2009 Undebuggable – who is killing my app?
Bugs
20 Oct 2007 Building an IoC container in 15 lines of code
IoC
01 Oct 2008 Meta tests
Test Driven Development