Naming test methods in Java [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
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?
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.
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
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?
@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.
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:
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
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.
7 Popular Unit Test Naming Conventions
Join the DZone community and get the full member experience.
The article presents a compiled list of unit tests naming strategy that one could follow for naming their unit tests. The article is intended to be a quick reference instead of going through multiple great pages such as following. That said, to know greater details, please feel free access one of these pages listed below and know for yourself.
Following are 7 popular unit tests naming conventions that are found to be used by majority of developers and compiled from above pages:
- MethodName_StateUnderTest_ExpectedBehavior: There are arguments against this strategy that if method names change as part of code refactoring than test name like this should also change or it becomes difficult to comprehend at a later stage. Following are some of the example:
- isAdult_AgeLessThan18_False
- withdrawMoney_InvalidAccount_ExceptionThrown
- admitStudent_MissingMandatoryFields_FailToAdmit
- MethodName_ExpectedBehavior_StateUnderTest: Slightly tweeked from above, but a section of developers also recommend using this naming technique. This technique also has disadvantage that if method names get changed, it becomes difficult to comprehend at a later stage. Following is how tests in first example would read like if named using this technique:
- isAdult_False_AgeLessThan18
- withdrawMoney_ThrowsException_IfAccountIsInvalid
- admitStudent_FailToAdmit_IfMandatoryFieldsAreMissing
- test[Feature being tested]: This one makes it easy to read the test as the feature to be tested is written as part of test name. Although, there are arguments that the “test” prefix is redundant. However, some sections of developer love to use this technique. Following is how the above tests would read like if named using this technique:
- testIsNotAnAdultIfAgeLessThan18
- testFailToWithdrawMoneyIfAccountIsInvalid
- testStudentIsNotAdmittedIfMandatoryFieldsAreMissing
- Feature to be tested: Many suggests that it is better to simply write the feature to be tested because one is anyway using annotations to identify method as test methods. It is also recommended for the reason that it makes unit tests as alternate form of documentation and avoid code smells. Following is how tests in first example would read like if named using this technique:
- IsNotAnAdultIfAgeLessThan18
- FailToWithdrawMoneyIfAccountIsInvalid
- StudentIsNotAdmittedIfMandatoryFieldsAreMissing
- Should_ExpectedBehavior_When_StateUnderTest: This technique is also used by many as it makes it easy to read the tests. Following is how tests in first example would read like if named using this technique:
- Should_ThrowException_When_AgeLessThan18
- Should_FailToWithdrawMoney_ForInvalidAccount
- Should_FailToAdmit_IfMandatoryFieldsAreMissing
- When_StateUnderTest_Expect_ExpectedBehavior: Following is how tests in first example would read like if named using this technique:
- When_AgeLessThan18_Expect_isAdultAsFalse
- When_InvalidAccount_Expect_WithdrawMoneyToFail
- When_MandatoryFieldsAreMissing_Expect_StudentAdmissionToFail
- Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior: This approach is based on naming convention developed as part of Behavior-Driven Development (BDD). The idea is to break down the tests into three part such that one could come up with preconditions, state under test and expected behavior to be written in above format. Following is how tests in first example would read like if named using this technique:
- Given_UserIsAuthenticated_When_InvalidAccountNumberIsUsedToWithdrawMoney_Then_TransactionsWillFail
My personal favorite is naming unit tests based on the writing features of the class under test. It helps me to make sure that a class follows single responsibility. It also aids a great deal in code refactoring.
Published at DZone with permission of Ajitesh Kumar , DZone MVB . See the original article here.
Opinions expressed by DZone contributors are their own.