Mark Needham

Thoughts on Software Development

BDD style unit test names

with 7 comments

A couple of my colleagues have been posting about how to name your unit tests based on this original post by Jay Fields.

I think that test names are useful, especially when written in a BDD style expressing what a test is supposed to be doing.

For example, in a C# NUnit test we might see the following as a test name:

public void ShouldDoSomething()
	// Code testing that we're doing something

I write all my tests like this and I’m often asked what the point of the ‘Should’ is, why not just name it ‘DoSomething’.

For me although it’s a subtle change it influences the way that people look at the test. They can look at the test in a much more critical way.

In the above example someone can look at the test name ‘ShouldDoSomething’ and then think ‘Actually no, it should be doing something else.’ The test name and the test contents can then be changed to fit this new understanding of the test.

I’m with Chris Johnston who says the following when it comes to naming tests:

One habit that I picked up on my last project was naming a test after I had written it. While creating the unit test, I would simply name it foo(). Then, once I saw what the code was actually doing, I would go back and rename the test to something appropriate.

Ideally I want to name the test properly before I write it but sometimes it becomes clear to me exactly what the name should be as I’m writing the test.

If I’m in this situation I usually just name the test ‘ShouldDoSomething’ and then by the time I’ve written it I know what it should actually be doing and I can go back and rename it.

In terms of the general argument over whether we should even have test names, I have only really coded tests in Java and C# so I’m not in a position to comment on whether using a language like Ruby means that they aren’t necessary.

For me the test name provides the intention of what you are trying to do, and I like to skim the list of tests in a class – by using Ctrl – F12 and then typing in ‘Should’ to filter the method list in Resharper – so that I can see at a high level what is supposed to be happening in that test fixture.

In the world of IntelliJ there is also a nice plugin called TestDox which allows you to get a list of your tests nicely indented with spaces.

Be Sociable, Share!

Written by Mark Needham

September 4th, 2008 at 12:05 am

  • Torbjörn Gyllebring

    Being a “Should” infected C# developer myself I just recently started casing tests like “should_do_something” instead of proper camelcasing them, this has the benefit of looking prettier in test runners it also help highlight any helper functions in test classes, overall I belive it’s an improvement, it helps me focus on “this is a test it follows a slightly diffrent set of rules” (i.e. can be a bit “moist” etc).

    Also if you like TestDox maybe can be of intrest.

  • Hey Mark,
    As I commented on Chris’s post:

    Perhaps if you don’t know how you want the code to behave, then you haven’t thought through the design of your story enough. I find if you test the behaviour, rather than what it is meant to do, then you usually know what you want to happen. Sometimes, I decide to push implementation down to other services, helpers, or lower down the stack, but I keep the original test inplace, and also have the test at the required unit level.

    Of course, there are always going to be those times when you really don’t know how the code will hang together. Pat Kua call these times experimentation Take his advice – use TDD when you are focused on the problem, and know how to solve it; use experimentation to find out how to solve it (and then quite possibly, revert all your changes and begin TDD)

  • Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #172()

  • @Sarah I was actually thinking that I was writing that line actually! I’m absolutely with you in terms of testing the behaviour of something rather than what it is meant to do.

    There have been times when myself and a pair have been almost sure what we want to test but we’re not quite sure how to phrase it – I guess those are the times when I write the test name at the end. Maybe we should have spent more time thinking of exactly what we want to test first although I don’t think it hurt us too much writing the test name last in those cases.

    Thanks for the link to Pat’s post.

    @Torbjörn I was reading about that naming convention in Neal Ford’s The Productive Programmer. I never really had a problem reading camel case stuff myself, nice idea though.

  • Torbjörn Gyllebring

    Another thing with using_underscores is that it makes it a tad easier for me, in situations like.

    ToStringShouldReturnSomething -> ToString_should_return_something

    basicly it let me writes tests that can contain methods, properties and classes in their description without having to re-parse CamelCaseing to know what’s the description and what is an actual type like:

    ShouldCallIDoStuffDoStuff -> should_call_IDoStuff_DoStuff

    Just a personal oppionion, on the “name after test” thing I have a bit of the same pattern for designing my tests, in my case it goes something like:

    1: Try to formulate test name.
    2: Write assert.
    3: Write the code to get to (2)

    If I get stuck on any one of theese and lacking a pair (Yes I know that it’s hard to belive but some of us have to live under circumstances like that) to help me out I skip to the next step and hope that I can get some clarity by doing that. Then when I (3) and (2) most of the time a good name will materialize, if not, I go take a coffee and restart the process.

  • Pingback: The Productive Programmer: Book Review at Mark Needham()

  • Pingback: Book Club: The Readability of Tests - Growing Object Oriented Software (Steve Freeman/Nat Pryce) at Mark Needham()