Quality Testing

Naming Test Classes

Test classes should represent one story or even more likely, part of one story. Test classes with a clear and small scope allow anyone to quickly identify what the class is doing. It is valid to have multiple test classes with multiple tests per user story that your team delivers.

Like test method naming, test classes should be named based on the feature and it should be easy to understand what that test class is doing simply based on the name.

ForgotPasswordTests is an example. It’s not specific to any page, and simply by the name of it you immediately have a pretty good understanding what that test class is about.

Going further, even this can be broken up or extended upon with additional test classes such as ResetPasswordTests, PasswordLockoutTests, PasswordCreationTests, PasswordStrengthIndicatorTests, and so on.

A good rule to follow would be that there should be at least as many test classes as your team has user stories, per sprint. Each of those classes should have multiple, smaller tests within it.