Do it: use ridiculously long test method names

“Dan North” (tastapod!) has a good write-up on what he is calling “BDD”: Behavior Drive-Development.

He does a much better job than I can do discussing all these items, but the thing that struck me is that almost all his conclusions can be reached by following just one piece of advice: make your test methods really expressive.

I started doing this in 2004 and it has been a huge help. My tests are more focussed, and because of that, I write more tests because it doesn’t take as much thought/energy. And in writing more tests, I often design my code better, and ultimately produce software faster. As a nice side effect, quality has gone up, but that is not the primary reason for TDD or BDD.

Unfortunately, Dan’s examples of test methods were rather weak – often the agiledox crowd uses really simplistic examples. So I thought I’d give some examples of some of my methods from HostedQA:

• parsingHostHandlesHttpAndHttpsAsWellAsOptionalPorts
• findingAnAccountByNameWorksAfterCreatingAnAccountOfTheSameName
• creatingNewAppConfigReturnsSameIdAsTheIdSetOnTheAppConfigReference
• findingAppConfigsForAProjectReturnsThemInAlphabeticalOrderByName

And my personal favorites (broken up with a space because they are so long):

• updatingAppConfigWithoutResourcesThat UsedToBeAssociatedWithItCausesThoseReferencesToBeDeleted
• deletingAPopulatedProjectCausesAllChild EntitiesToAlsoBeDeletedAndTheProjectIsCompletelyDeleted

Kind of annoyingly long methods? Absolutely. But not only, as Dan points out, is it easier to know what went wrong when a failure occurs, it is also almost brainless to implement these tests (and thereby design your application in the most direct manner possible).

If my test requires that I test that “updating an app config without resources that used to be associated with it causes those references to be deleted”, it’s really easy to know what I need to test – it’s literally spelled out for me.

As a small note: Dan recommends that tests usually have “should” in front of them. I prefer to think that all my test methods (I use TestNG, so I don’t have “test” in the method names) have “test that” prepended in front of the sentence. Ie: “test that adding X and Y results in Z” becomes addingXAndYResultsInZ.