Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

TDD: Expressive test names

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.

This entry was posted in tdd, testing. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to TDD: Expressive test names

  1. Arnis L. says:

    YouShouldNotBotherBecauseNoOneReadsThoseUberLongTestNamesAnyway

    —-

    ‘What_When_Results’ syntax is much better.
    In your case I would write it like this:

    fooTests
    Clone_IgnoresId
    Clone_IgnoresCompletedFlag

    Because there really isn’t specific state (I assume so), we omit ‘When’ part completely.
    Description why this exact functionality is necessary should go in comments.

    This approach delegates exposition of information about testable unit from test name to, as i call it – ‘just knowing the context’.

    That decreases receivable information at moment you read your failed continuous integration report (which doesn’t matter much cause You will need to fix it anyway), but increases maintainability and readability of Your test code.

  2. Bernhard says:

    I read the “should” in so many unit tests and it still bugs the hell out of me. Unit tests are a MUST, not a SHOULD as per RFC 2119: http://www.ietf.org/rfc/rfc2119.txt

  3. Rob Miles says:

    I think naming tests and test fixtures as specifically as possible is a crucial part of developing a maintainable and effective test suite. Without it then future developers are often tempted to cram more and more asserts into tests which dilutes the intention of the original tests and means that when a test fails, its name often gives you no hint as to why. The Whenxxxxx / Shouldyyyyyy style has given me great results in the past.

  4. Craig Beck says:

    I have suffered through the same issue with generically named tests that I’m doing the same thing. I would rather be using a proper BDD testing framework that makes this even clearer, but this makes for a decent enough compromise when using something like NUnit that I can deal with it.

Leave a Reply