7 Popular Unit Test Naming Conventions and Best Practices

This article presents a compiled list of naming strategies that one could follow for naming their unit tests. It is intended to be a quick reference for unit test naming conventions. 

That said, to see more details, please feel free access one of these pages listed below for deeper information:

• What are some popular naming conventions for unit tests?
• Unit Tests Naming Best Practices
• Given-When-Then Technique
• How to Unit Test Stream Pipelines and Lambdas
• CI/CD Pipeline Testing

The following list is comprised of seven popular unit tests naming conventions that are used by majority of developers and compiled from above pages:

Unit Test Naming Convention 1: MethodName_StateUnderTest_ExpectedBehavior

MethodName_StateUnderTest_ExpectedBehavior: There are arguments against this strategy that if method names change as part of code refactoring, then the test name like this should also change or it becomes difficult to comprehend at a later stage. Following are some of the examples:

• isAdult_AgeLessThan18_False
• withdrawMoney_InvalidAccount_ExceptionThrown
• admitStudent_MissingMandatoryFields_FailToAdmit

Learn Software Testing and Automation*

*Affiliate link. See Terms of Use.

Unit Test Naming Convention 2: MethodName_ExpectedBehavior_StateUnderTest

MethodName_ExpectedBehavior_StateUnderTest: Slightly tweaked from above, and a section of developers also recommend using this naming technique. This technique also has the disadvantage that if method names get changed, it becomes difficult to comprehend at a later stage. The following is comprised of how tests in first example would read if named using this technique:

• isAdult_False_AgeLessThan18
• withdrawMoney_ThrowsException_IfAccountIsInvalid
• admitStudent_FailToAdmit_IfMandatoryFieldsAreMissing

Unit Test Naming Convention 3: test[Feature being tested]

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 developers love to use this technique. The following list is how the above tests would read if named using this technique:

• testIsNotAnAdultIfAgeLessThan18
• testFailToWithdrawMoneyIfAccountIsInvalid
• testStudentIsNotAdmittedIfMandatoryFieldsAreMissing
  

Unit Test Naming Convention 4: Feature to be tested

Feature to be tested: Many suggest that it is better to simply write the feature to be tested because one is using annotations to identify the method as test methods. It is also recommended for the reason that it makes unit tests as an alternate form of documentation and avoids code smells. The following list is how tests in first example would read if named using this technique:

• IsNotAnAdultIfAgeLessThan18
• FailToWithdrawMoneyIfAccountIsInvalid
• StudentIsNotAdmittedIfMandatoryFieldsAreMissing

Unit Test Naming Convention 5: Should_ExpectedBehavior_When_StateUnderTest

Should_ExpectedBehavior_When_StateUnderTest: This technique is also used by many as it makes it easy to read the tests. The following list is how tests in first example would read if named using this technique:

• Should_ThrowException_When_AgeLessThan18
• Should_FailToWithdrawMoney_ForInvalidAccount
• Should_FailToAdmit_IfMandatoryFieldsAreMissing

Unit Test Naming Convention 6: When_StateUnderTest_Expect_ExpectedBehavior

When_StateUnderTest_Expect_ExpectedBehavior: The following list is how tests in first example would read if named using this technique:

• When_AgeLessThan18_Expect_isAdultAsFalse
• When_InvalidAccount_Expect_WithdrawMoneyToFail
• When_MandatoryFieldsAreMissing_Expect_StudentAdmissionToFail

Unit Test Naming Convention 7: Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior

Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior: This approach is based on a 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 the above format. The following list is how tests in first example would read 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.