Don’t be afraid of long test names

When writing unit tests, I often write long test method names such as the following. The example is from a data access class.

aFooIsPersistedAsABar()

anExistingBazIsReusedWhenPersistingAFoo()

anExistingBarIsUpdatedWhenRecivingAnotherFooForSameQux()

anExistingBarIsRemovedWhenThereIsNoCorrespondingFoo()

To some people, method names as long as this may feel… wrong. Simply too long. I think this is taking a rule which is good in one context as an absolute law. Short method names are preferable in implementation code, because you typically make one or more calls to the method. If the method name is too long the calling code becomes awkwardly word-wrapped and hard to read.

This is not the situation with tests, however. You typically never make a call to one of the test methods manually – the testing framework does this for you.

Some people doesn’t even think very long method names are allowed. They can be as long as you want. (Almost.)

An identifier is an unlimited-length sequence of Java letters and Java digits, the first of which must be a Java letter.

Of course, for most rules there is an equally valid rule saying the opposite. An unnecessarily long name just gets hard to read for no benefit. You don’t want your test names to extend into short stories, and you most certainly want to stay within the allowed line length you are using. But if you are used to writing test method names that are 5-15 characters long, go ahead and be a bit extravagant. Explain to me what the test actually does. Tell me both the input and the output. Use as many letters as you need (but no more).

Leave a Reply