6

Over at codereview a comment hinted that using snake_case to name test methods is a good idea.

This contradicted my views and I did some research and there seem to be a lot of examples that actually use snake_case for this.

Myself, I use classic camelCase names like testXyz for unit tests or a BDD approach givenXyzWhenXyzThenXyz for integration tests.

There also is a third option that combines both ways, e.g. useCase_WhenSomething_ThenAssertion.

My question is: What are good arguments for either using snake_case or camelCase to name test methods?

I'd like to start this with a few arguments from my experience and work:

In Favor of camelCase

  • It follows the general Java coding conventions of using camelCase.
  • It is consistent with production code.
  • I personally find camelCase no harder to read than snake_case – I'm used to descriptive names from production code anyway.
  • IDE support suffers when using snake_case (at least Eclipse).

In Favor of snake_case

  • Some frameworks can generate reports from tests and using snake_case allows such frameworks to create correct sentences from the test names.

In Favor of a combination of both

  • ?

What are other arguments? How does maybe the pattern in which the test methods are named affect the arguments?

Little disclaimer: Of course, ultimatively it comes down to team conventions. However, it might be worth discussing pros and cons for certain conventions.

closed as primarily opinion-based by gnat, Konrad Morawski, user40980, jwenting, GlenH7 May 1 '14 at 14:06

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    It would be interesting to add to the question combination of both naming methods, for example create_NoCountryAssociation_ExceptionThrown. Following this standard - osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html – user128725 May 1 '14 at 8:55
  • @JakubPolák I added it! – Ingo Bürk May 1 '14 at 9:44
  • using snake_case allows such frameworks to create correct sentences from the test names - I don't know the frameworks, but why is it impossible for them to create equally correct sentences out of camelCase names? – Konrad Morawski May 1 '14 at 11:13
  • 1
    @KonradMorawski Because you have trouble using acronyms and capitalizing the sentence correctly. One of my colleagues actually ended up writing such a framework himself that we use now. – Ingo Bürk May 1 '14 at 11:17
11

I'll drop a few cents since it's my comment being referred to.

I, also, got this naming approach from Roy Osherove and I particularly like it. Following a methodname that is built in this manner we can have something like this:

createUser_WithNonExistingEmail_ShouldThrowArgumentException

In standard camelCasing this becomes

createUserWithNonExistingEmailShouldThrowArgumentException

It's not unreadable, but it is a lot harder to read. The reason these explicit underscores are added is because the method names are per definition a lot longer if you make them as descriptive as suggested by Osherove.

A unit test's methodname has to combine several aspects. It should contain

  • The unit under test
  • The scenario that's being tested
  • The expected return value

A non-unit test's methodname has to contain

  • The main action performed by that method

This summary alone should indicate that this is a special kind of method. I feel like we can divert from the path of the conventions because the intention behind method names in this scenario is different from traditional methods (which were kept in mind when the conventions were made).

Unit tests are different from traditional methods in a few other ways as well: they will never get called by you explicitly and so they should just be as readable and descriptive as possible for your test results.

Not the answer you're looking for? Browse other questions tagged or ask your own question.