» Behavior (verbs) as Test Class Names » Managed Chaos by Naresh Jain

Behavior (verbs) as Test Class Names

For the last 3 odd years, I’ve been exploring the use of behavior (verbs, instead of Nouns, Test) as my test class names. The verb describes what behavior you expect from your system (program).

For example for a Veterinarian Information System (system responsible for billing and patient history), I would have tests called:

ChargeAccountForServices with the following test methods:

makePaymentsAgainstAnAccount()
completePaymentsResultInZeroAmountDueOnReceipt()
incompletePaymentsDisplaysDueAmountOnTheReceipt()

Another test class: GenerateBillsForClientAccount with

notifyIfAccountIsNotDueForPayment()
billContainsTotalCostOfAllServicesTaken()

And another test class: ManageClientVisits with

trackAllServicesTakenByThePatient()
skipVisitIfPatientDidNotTakeAnyService()

These tests helped us flush out Objects like Account, Procedure, Visit and so on…. When we started we had no idea we’ll need these objects.

This style is mostly influenced from a pairing session with Corey Haines post our discussion about “There is no Spoon” @ the SDTConf 2006.

For more about this approach…read my last post…There is No Spoon (Objects)

This entry was posted on Monday, June 15th, 2009 at 2:13 PM and is filed under Design, Programming, 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.

Chuck van der Linden

a verb isn’t enough… verbs on their own don’t tell us anything.

what you need is effectively a sentence. tell me what behavior of the method/program the test is veifying. Tell me both the test action and the expected result. Some of your examples above are pretty good at doing that, but others describe only some action, and stop short of giving the result. For example

makePaymentsAgainstAnAccount()

ok so I know what action the test is taking, it makes a payment, but what should happen as a RESULT of that action?

Compare that against:
accountBalanceProperlyAdjustedWhenPaymentMadeAgainstAccount()

NOW you know what it’s doing. better yet when it fails you know more about exactly isn’t working as it should. And if you use a utility such agiledox against those test names, you get a result that means something to the non-programmers like QA, PO’s, BA’s and your customer.

I’m not sure how far back this goes, but the first person I saw talking about it was Dan North. To quote from a blog post of his back in 2006
—=-=-=-=
Test method names should be sentences

My first “Aha!” moment occurred as I was being shown a deceptively simple utility called agiledox, written by my colleague, Chris Stevenson. It takes a JUnit test class and prints out the method names as plain sentences, so a test case that looks like this:

public class CustomerLookupTest extends TestCase {
testFindsCustomerById() {
…
}
testFailsForDuplicateCustomers() {
…
}
…
}

renders something like this:

CustomerLookup
- finds customer by id
- fails for duplicate customers
- …

The word “test” is stripped from both the class name and the method names, and the camel-case method name is converted into regular text. That’s all it does, but its effect is amazing.

Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences. What’s more, they found that when they wrote the method name in the language of the business domain,the generated documents made sense to business users, analysts, and testers.
–=-=-=-=
You can read more on this at the linked blog post.
Chuck van der Linden

a verb isn’t enough… verbs on their own don’t tell us anything.

what you need is effectively a sentence. tell me what behavior of the method/program the test is veifying. Tell me both the test action and the expected result. Some of your examples above are pretty good at doing that, but others describe only some action, and stop short of giving the result. For example

makePaymentsAgainstAnAccount()

ok so I know what action the test is taking, it makes a payment, but what should happen as a RESULT of that action?

Compare that against:
accountBalanceProperlyAdjustedWhenPaymentMadeAgainstAccount()

NOW you know what it’s doing. better yet when it fails you know more about exactly isn’t working as it should. And if you use a utility such agiledox against those test names, you get a result that means something to the non-programmers like QA, PO’s, BA’s and your customer.

I’m not sure how far back this goes, but the first person I saw talking about it was Dan North. To quote from a blog post of his back in 2006
—=-=-=-=
Test method names should be sentences

My first “Aha!” moment occurred as I was being shown a deceptively simple utility called agiledox, written by my colleague, Chris Stevenson. It takes a JUnit test class and prints out the method names as plain sentences, so a test case that looks like this:

public class CustomerLookupTest extends TestCase {
testFindsCustomerById() {
…
}
testFailsForDuplicateCustomers() {
…
}
…
}

renders something like this:

CustomerLookup
- finds customer by id
- fails for duplicate customers
- …

The word “test” is stripped from both the class name and the method names, and the camel-case method name is converted into regular text. That’s all it does, but its effect is amazing.

Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences. What’s more, they found that when they wrote the method name in the language of the business domain,the generated documents made sense to business users, analysts, and testers.
–=-=-=-=
You can read more on this at the linked blog post.
http://neilmartinagile.wordpress.com/ neil martin

What you need is nbehave i posted about it against this tag here : http://neilmartinagile.wordpress.com/tag/nbehave/

NBehave will help you form sentances and make your tests flow add into that some fluent builders and your starting to have a conversation in code you can also download a more complete example here that i wrote recently :
https://www.box.net/shared/pdis5i6k7s

I also think this Auto naming script might help you out :
https://www.box.net/shared/csvfrst4it

you can find out how to use it here :

http://neilmartinagile.wordpress.com/2008/06/08/shallow-dive-with-bdd/

kind regards
Neil Martin
http://neilmartinagile.wordpress.com neil martin

What you need is nbehave i posted about it against this tag here : http://neilmartinagile.wordpress.com/tag/nbehave/

NBehave will help you form sentances and make your tests flow add into that some fluent builders and your starting to have a conversation in code you can also download a more complete example here that i wrote recently :
https://www.box.net/shared/pdis5i6k7s

I also think this Auto naming script might help you out :
https://www.box.net/shared/csvfrst4it

you can find out how to use it here :

http://neilmartinagile.wordpress.com/2008/06/08/shallow-dive-with-bdd/

kind regards
Neil Martin
Chuck van der Linden

StoryQ is another .net based tool for this I’ve heard of, but not used.

In the Ruby language, there are RSpec and Cucumber, which are arguabley two of the most advanced tools for BDD style testing at both the unit test level, and also higher levels such as integration and acceptance tests.

As a QA person I use Cucumber, Watir, and Watircraft to run ‘scripts’ consisting of BDD style plain language scenarios to do acceptance testing against a web based product built in .net. it is very good stuff. I’m hoping to get my devs hooked on something like StoryQ or Nbehave
Chuck van der Linden

StoryQ is another .net based tool for this I’ve heard of, but not used.

In the Ruby language, there are RSpec and Cucumber, which are arguabley two of the most advanced tools for BDD style testing at both the unit test level, and also higher levels such as integration and acceptance tests.

As a QA person I use Cucumber, Watir, and Watircraft to run ‘scripts’ consisting of BDD style plain language scenarios to do acceptance testing against a web based product built in .net. it is very good stuff. I’m hoping to get my devs hooked on something like StoryQ or Nbehave