Naresh Jain » Agile FAQs Blog » Managed Chaos » Naming Style of my Test Methods is changing…

Naming Style of my Test Methods is changing…

Long back, I’ve moved away from naming my test methods as test<something> to should<do_something>.

    @Test
    public void shouldIgnoreDuplicateDocuments() {
        ...
    }

For the last year or so, I’ve moved away from the “should” naming conversion as well. These days my tests look like:

    @Test
    public void ignoreDuplicateDocuments() {
        ...
    }

More examples:

    @Test
    public void removeDocumentsBasedOnName() {
        ...
    }

From a Domain Forwarding server code:

    @Test
    public void redirectDomainsWithSubDomainsAndPathPermanently() {
        ...
    }

To think about it the “should” just seems redundant and lots of times gets in the way of freely expressing what behavior you are trying to drive.

This entry was posted on Sunday, May 24th, 2009 at 10:32 PM and is filed under Agile, Design, Testing. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

http://www.m3p.co.uk/blog Steve Freeman

Why not just use the TestDox style?

“A Thingy” removesDocumentsBasedOnName
“A Thingy” redirectsDomainsWithSubDomainsEtc
http://www.m3p.co.uk/blog Steve Freeman

Why not just use the TestDox style?

“A Thingy” removesDocumentsBasedOnName
“A Thingy” redirectsDomainsWithSubDomainsEtc
http://agilefaqs.com/nareshjain.html Naresh Jain

I guess the 2 styles are very similar except that AgileDox’s style is “removes….” (passive), while my style is “remove…” (active).

When I’m driving my development using tests, I find myself anthropomorphizing. As a test, I’m telling (in active voice) to the class under construction/conceptualization, what I want it to do. Its a conversion between me and the production class, expressed as tests.

If I look at the AgileDox or the “Should” convention, the test names are not a conversation between the test and the production class. The target audience is someone else (may be the next developer who is going to read the code or some tool), rather than the production code.
http://agilefaqs.com/nareshjain.html Naresh Jain

I guess the 2 styles are very similar except that AgileDox’s style is “removes….” (passive), while my style is “remove…” (active).

When I’m driving my development using tests, I find myself anthropomorphizing. As a test, I’m telling (in active voice) to the class under construction/conceptualization, what I want it to do. Its a conversion between me and the production class, expressed as tests.

If I look at the AgileDox or the “Should” convention, the test names are not a conversation between the test and the production class. The target audience is someone else (may be the next developer who is going to read the code or some tool), rather than the production code.
http://www.m3p.co.uk/blog Steve Freeman

I think the AgileDox approach is “descriptive”, rather than passive. The intention is to leave behind a description of the class, but without the redundancy of “should”.
http://www.m3p.co.uk/blog Steve Freeman

I think the AgileDox approach is “descriptive”, rather than passive. The intention is to leave behind a description of the class, but without the redundancy of “should”.
http://twitter.com/amoljb Amol Jadhav

Leaving underscore in tests is a new naming style that is becoming more popular day by day. I find it much readable, a blog from Justin Etheredge had very nice snapshot of it.
http://twitter.com/amoljb Amol Jadhav

Leaving underscore in tests is a new naming style that is becoming more popular day by day. I find it much readable, a blog from Justin Etheredge had very nice snapshot of it.
http://agilefaqs.com/nareshjain.html Naresh Jain

Thanks Amol for the suggestion. I like the underscore in my testnames.

Also what Justin has highlighted is a very kewl concept. I’ve written tests where my test fixture (class) names are verbs. They describe a context. And then my tests (method) names, describe all the relevant behavior/scenario. It makes my tests extremely readable. I mostly follow this pattern for my acceptance tests.
http://agilefaqs.com/nareshjain.html Naresh Jain

Thanks Amol for the suggestion. I like the underscore in my testnames.

Also what Justin has highlighted is a very kewl concept. I’ve written tests where my test fixture (class) names are verbs. They describe a context. And then my tests (method) names, describe all the relevant behavior/scenario. It makes my tests extremely readable. I mostly follow this pattern for my acceptance tests.
John Stoneham

Steve showed me a concept that’s turned out some very comprehensible test code: your test method names, when listed in the Outline/Structure view of your IDE, ought to read as a rough specification of the behavior of the class under test. Present tense works well.

This helps me focus on the behavior being demonstrated and usually requires me to express the postcondition verbally.

@Test void valueIsNullWhenCalledBeforeInitialize() { … }
@Test void executeCommandCallsServiceMethod() { … }
@Test void playCdSignalsHardwareInterface() { … }
@Test void fireThrowsIfGunIsNotLoaded() { … }

This is a little more painful in JUnit 3, but not too bad:

void testValueIsNullWhenCalledBeforeInitialize() { … }
void testExecuteCommandCallsServiceMethod() { … }
void testPlayCdSignalsHardwareInterface() { … }
void testFireThrowsIfGunIsNotLoaded() { … }

The underscore idea is starting to sound pretty nice these days:

void value_is_null_when_called_before_initialize() { … }
void executeCommand_calls_service_method() { … }
void playCd_signals_hardware_interface() { … }
void fire_throws_if_gun_is_not_loaded() { … }
John Stoneham

Steve showed me a concept that’s turned out some very comprehensible test code: your test method names, when listed in the Outline/Structure view of your IDE, ought to read as a rough specification of the behavior of the class under test. Present tense works well.

This helps me focus on the behavior being demonstrated and usually requires me to express the postcondition verbally.

@Test void valueIsNullWhenCalledBeforeInitialize() { … }
@Test void executeCommandCallsServiceMethod() { … }
@Test void playCdSignalsHardwareInterface() { … }
@Test void fireThrowsIfGunIsNotLoaded() { … }

This is a little more painful in JUnit 3, but not too bad:

void testValueIsNullWhenCalledBeforeInitialize() { … }
void testExecuteCommandCallsServiceMethod() { … }
void testPlayCdSignalsHardwareInterface() { … }
void testFireThrowsIfGunIsNotLoaded() { … }

The underscore idea is starting to sound pretty nice these days:

void value_is_null_when_called_before_initialize() { … }
void executeCommand_calls_service_method() { … }
void playCd_signals_hardware_interface() { … }
void fire_throws_if_gun_is_not_loaded() { … }
Simon Cromarty

There's a gotcha with taking the “should” out of these tests.
You're describing what the test does but not saying whether the result should be “successful” or not. This is fine for pass cases but what about boundaries and negatives? – do you have a specific convention to clearly indicate that something “shouldn't”?