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.

  • 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
    Commented May 1, 2014 at 8:55
  • @JakubPolák I added it!
    – Ingo Bürk
    Commented May 1, 2014 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? Commented May 1, 2014 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
    Commented May 1, 2014 at 11:17

1 Answer 1


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:


In standard camelCasing this becomes


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.