Mark Needham

Thoughts on Software Development

TDD: Expressive test names

with 4 comments

Towards the end of a post I wrote just over a year ago I suggested that I wasn’t really bothered about test names anymore because I could learn what I wanted from reading the test body.

Recently, however, I’ve come across several tests that I wrote previously which were testing the wrong thing and had such generic test names that it wasn’t obvious that it was happening.

The tests in question were around code which partially clones an object but doesn’t copy some fields for various reasons.

Instead of documenting these reasons I had written tests with names like this:

[Test]
public void ShouldCloneFooCorrectly() { }
[Test]
public void ShouldSetupFooCorrectly() { }

When we realised that the code wasn’t working correctly, which didn’t happen until QA testing, these test names were really useless because they didn’t express the intent of what we were trying to test at all.

Damian and i spent some time writing more fine grained tests which described why the code was written the way it was.

We also changed the name of the test fixture to be more descriptive as well:

[TestFixture]
public class WhenCloningFooTests
{
	[Test]
	public void ShouldNotCloneIdBecauseWeWantANewOneAssignedInTheDatabase() { }
 
	[Test]
	public void ShouldNotCopyCompletedFlagBecauseWeWantTheFooCompletionJobToPickItUp() { 	
}

It seems to me that these new tests names are more useful as specifications of the system behaviour although we didn’t go as far as you can with some frameworks where you can create base classes and separate methods to describe the different parts of a test.

Despite that I think naming tests in this way can be quite useful so I’m going to try and write more of my tests like this.

Of course it’s still possible to test the wrong thing even if you are using more expressive names but I think it will make it less likely.

Be Sociable, Share!

Written by Mark Needham

March 19th, 2010 at 6:06 pm

Posted in Testing

Tagged with

  • skim

    Could this be one of the reasons why BDD is getting so popular? Referring back to your bowling kata tests, Screw.Unit allows for a long descriptive string in the describe function.

    I also wonder if there is such a thing as “too long” for method names in TDD.

  • sud

    Expressive method names in tests are the way to go from a readability perspective…and better still use _ as word separators instead of Hungarian notation.

    So ShouldCloneFooCorrectly becomes should_clone_foo_correctly

    takes readability to the next level. This is along the principle that code is only written once but read multitudes of times. To be honest when I first saw the “_” notation I was aghast! But now I do it for all my test method names and all my co-workers have adopted it to.

  • Totally agree with skim, I didn’t really get TDD until i started using MSPEC and i *KNEW* what i was testing

  • MM

    Roy Osherove’s suggested approach of MethodName_StateUnderTest_ExpectedBehavior (e.g. IsValidFileName_ValidFile_ReturnsTrue()) has been working pretty well for me so far.