Why you should test code too silly to break
time to read 1 min | 183 words

I wrote a test for this piece code:

public virtual void View([ARFetch("id")]Webcast webcast)
{
    PropertyBag["webcast"] = webcast;
}

Now, this looks like utter lunacy, isn't it? Especially when the test looks like:

[Test]
public void When_view_called_will_send_webcast_to_view()
{
	var webcast = new Webcast();
	controller.View(webcast);

	controller.PropertyBag["webcast"].ShouldBeTheSameAs(webcast);
}

Except that now that I have covered the very basic item, I now have another few tests:

[Test]
public void When_view_called_with_null_webcast_will_render_missing_webcast_view()
{
	controller.View(null);

	controller.SelectedViewName.ShouldEqual(@"Webcast\Missing");
}

[Test]
public void When_view_called_with_unpublished_webcast_will_render_unpublished_webcast_view()
{
	controller.View(new Webcast());

	controller.SelectedViewName.ShouldEqual(@"Webcast\Unpublished");
}

And the simplest thing that can make those test pass is:

public virtual void View([ARFetch("id")]Webcast webcast)
{
	if(webcast==null)
	{
		RenderView("Missing");
		return;
	}
	if(webcast.PublishDate==null)
	{
		RenderView("Unpublished");
		return;
	}
        PropertyBag["webcast"] = webcast;
}

By having tests from the beginning, even for trivial piece of code, I ensured both that the trivial case will work and that I am already starting with the right tone.

0 comments
Tags:

Related posts that you may find interesting:

13 Jun 2008 Pain reduction: creating ductile tests
Castle Test Driven Development
17 Jun 2008 Zero Friction: Creating a test model
Design Test Driven Development
10 Jun 2008 How many tests?
Test Driven Development