Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Heavyweight tests == lots of future pain

Anyone that has written tests in the past knows that they can be a life saver.  They can help to flush out application bugs as well as deisgn issues very early in the process.  You also know that poorly written unit tests make for a pain to maintain.  The same can be said for heavy unit tests. 

What constitutes a 'heavy' test?  A heavy test is one which multiple items are being asserted.  Please note, I am not saying that simply having multiple asserts is bad, but asserting disjoined items is bad.

Example of light, simple test

public void SomeTest()
{
	ISomeObject someObject = new SomeObject();

	ISomeReturnValue someReturnValue = someObject.GetSomeValueByString( "someKeyProvieded" );

	Assert.That( someReturnValue, Is.Not.Null );
        Assert.That( someReturnValue.SomeProperty, Is.EqualTo( 123 ) );
        Assert.That( someReturnValue.SomeKey, Is.EqualTo( "someKeyProvieded" ) );
}

The code above may have multiple asserts, but they are all on the same object and are all based around the same call.  This test is lightweight and could be very easily refactored to meet future changes.

Example of heavy, complex test

public void SomeTest()
{
	ISomeObject someObject = new SomeObject();

	ISomeReturnValue someReturnValue = someObject.GetSomeValueByString("someKeyProvieded");

	Assert.That(someReturnValue, Is.Not.Null);
        Assert.That(someReturnValue.SomeProperty, Is.EqualTo(123));
        Assert.That(someReturnValue.SomeKey, Is.EqualTo("someKeyProvieded"));

	//  below tests are the start of the heavy part... starting to test something completely different.
	ISomeSecondObject someSecondObject = new SomeSecondObject();
            
        IAnotherObject anotherObject;
            
        if ( someReturnValue.SomePropety == 1 )
        {
        	anotherObject = someReturnValue.SomeSecondaryMethod("PapaSmurf");
                Assert.That(anotherObject, Is.Not.Null);
                Assert.That(anotherObject.Items.Count, Is.EqualTo(10));
       	}
        else
        {
                anotherObject = someReturnValue.SomeSecondaryMethod("Smurfette");
                Assert.That(anotherObject, Is.Not.Null);
                Assert.That(anotherObject.Items.Count, Is.EqualTo(5));
       	}
}

(NOTE: This is only an example)

The test above is actually multiple tests in one, it is real heavy and will cause pain later.  The top part of the test is testing one feature, while the second part (below the comment) is testing one of 2 different possible scenarios. 

In my opinion, the second tests should really be split out into 3 separate tests.  By separating this out you will create smaller tests that each have a single responsibility.  This will allow you to be able to more easily refactor your tests in the future should the need arise.

One of the largest reasons that teams abandon tests is that they cause too much pain or they are too costly to maintain.  And if the tests take too much effort to maintain, they will be abandoned, thus being a complete waste of time and money.  Sadly because of this bad experience, many developers on that team get a sour taste in the mouth for testing and more than likely will not go back to testing in the future. 

We need to keep in mind the real goals of testing:

  • Increase the confidence/reliability in our code
  • Increase the ability to make changes
  • Reduces the friction in development
  • Can reduce the complexity of your code base
  • It is fun (ok, this may be a stretch)

If by creating your tests you violate or ignore any of the goals above, you are setting yourself up for a painful experience.

Till next time,


Posted 04-02-2008 8:19 AM by Derik Whittaker

[Advertisement]

Comments

Reflective Perspective - Chris Alcock » The Morning Brew #65 wrote Reflective Perspective - Chris Alcock » The Morning Brew #65
on 04-03-2008 2:48 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #65

DotNetKicks.com wrote Heavyweight tests == lots of future pain
on 04-03-2008 8:58 AM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)