Tests (test cases) can be grouped into sets (test suites). If testing fails, the programmer will see the names of the culprits – suites and tests. In this regard, the name should inform the programmer about the causes of the trouble and the modules involved.
The name can be useful in other cases as well. For example, a customer found an error in the program, which means that the programmer must either add a new test or fix the existing one. Therefore, you need to be able to find the test by the nature of the error, and well-chosen names can help in this.
Typically, the test name consists of the name of the class or function being tested and reflects the specifics of the tested behavior. For example, the names TestIncorrectLogin and TestWeakPasswordRegistration could be used to check the correctness of the login and the module’s reaction to a too simple password.
Tests can be located both with the tested code, and in a separate project. Obviously, the main project shouldn’t depend on tests, it doesn’t need to know that someone is testing it. It is considered good practice to separate tests and production code, but there are exceptions – for example, if we need to check the implementation, i.e. the correctness of the work of its private methods of the class. In this case, tests can be placed right inside the code under test (or a friendship relationship between the class under test and the test is used). Usually there is no such need, and only the interface is covered with tests, since it is he who shapes the behavior of the class.