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
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.