Naming conventions help to organize tests better, so that it is easier for developers to find what they're looking for. Another benefit is that many tools expect that those conventions are followed. There are many naming conventions in use, and those presented here are just a drop in the ocean. The logic is that any naming convention is better than none. Most important is that everyone on the team knows what conventions are being used and are comfortable with them. Choosing more popular conventions has the advantage that newcomers to the team can get up to speed fast, since they can leverage existing knowledge to find their way around.

Common practice is to have at least two source directories. Implementation code should be located in src/main/java and test code in src/test/java. In bigger projects, the number of source directories can increase, but the separation between implementation and tests should remain as is.

Build tools such as Gradle and Maven expect source directory separation as well as naming conventions.

You might have noticed that the build.gradle files that we used throughout this book did not explicitly specify what to test, nor what classes to use to create a .jar file. Gradle assumes that tests are in src/test/java and that the implementation code that should be packaged into a JAR file is in src/main/java.

As stated in the previous practice, even though packages are the same, classes are in separate source directories.

All exercises throughout this book followed this convention.

One commonly used practice is to name tests the same as the implementation classes, with the suffix Test. If, for example, the implementation class is TickTackToe, the test class should be TickTackToeTest.

However, in all cases, with the exception of those we used throughout the refactoring exercises, we prefer the suffix Spec. It helps to make a clear distinction that test methods are primarily created as a way to specify what will be developed. Testing is a great sub-product of those specifications.

Using method names that describe tests is beneficial when trying to figure out why some tests failed or when the coverage should be increased with more tests. It should be clear what conditions are set before the test, what actions are performed, and what the expected outcome is.

There are many different ways to name test methods, and our preferred method is to name them using the Given/When/Then syntax used in the BDD scenarios. Given describes (pre)conditions, When describes actions, and Then describes the expected outcome. If a test does not have preconditions (usually set using @Before and @BeforeClass annotations), Given can be skipped.

Let's take a look at one of the specifications we created for our Tic-Tac-Toe application:

    @Test 
    public void whenPlayAndWholeHorizontalLineThenWinner() { 
        ticTacToe.play(1, 1); // X 
        ticTacToe.play(1, 2); // O 
        ticTacToe.play(2, 1); // X 
        ticTacToe.play(2, 2); // O 
        String actual = ticTacToe.play(3, 1); // X 
        assertEquals("X is the winner", actual); 
    } 

Just by reading the name of the method, we can understand what it is about. When we play and the whole horizontal or vertical and diagonal line is populated, then we have a winner.