Chapter 9. Organization Of Tests
Why does this matter? To be perfectly frank, usually it does not matter so much. Having tests in the same package gives you the following:
•there is no need to import some classes (e.g. the SUT class) into your tests, making your imports list shorter,
•it is possible to test some cumbersome cases by relaxing the access modifiers of some methods to "default" (see Section 7.5 and Section 7.6).
On the other hand, keeping test classes in different packages results in the following:
•you can not use the "default" access modifier to test private methods
• …however, you can still use a protected access modifier.
•it is very clear which classes belong to production code and which to test code; while it is usually not a problem for test classes (as they are pre/suffixed with Test), it might be important for various utility classes of test code.
I would encourage you to use a different package for tests, as it makes it harder to do things which, under normal circumstances, should be avoided (once again - private method testing, as well as certain other dubious techniques). However, this decision is not so very important, and can easily be changed if required (changing the package of tests will not break any clients, as usually no other code depends on test classes).
9.2. Name Your Tests Consistently
The naming schema of test classes and test methods can make a real difference. If consistent and well thought out, it will help you go to the right place in your code - exactly where you want to be. If chaotic, with no obvious patterns, it will slow down your development by forcing you to browse through your codebase class by class instead of jumping instantly to this one important place. Another important thing about naming is that it helps us to understand the role and purpose of each test. This is very important when adding new tests or when looking to identify the reason for a particular test failure.
In this section we will take a look at two main factors which impact on how hassle-free or problematic your experience of working with test code is likely to be: names of test classes and names of test methods. Additionally we will also consider naming schemas for test-doubles.
9.2.1. Test Class Names
The most popular pattern for naming test classes is to append a Test suffix to the name of the class being
tested. This results in test classes like UserDAOTest, PasswordValidatorTest and BankAccountTest, which
test production classes named UserDAO, PasswordValidator and BankAccount respectively. The benefits of this pattern are the following:
•it is dead simple,
•it is honored by a number of tools which:
•streamline the process of configuring the testing plugins of build tools (e.g. Maven, Gradle), as classes with the Test suffix are recognized by default as test classes,
191
Chapter 9. Organization Of Tests
•allow you to move quickly between test and production code with your IDE (so, for example, you can jump from BankAccount to BankAccountTest with one keyboard shortcut),
•there is a one-to-one mapping between production class and test class, so you know that:
•all tests of the given class are in this one place,
•and, vice-versa, that this test class contains nothing but tests for a single class,
•it is commonly used (so everyone feels at home when your code follows this schema).
There are not many counterproposals for test class naming schemes1. The overwhelming majority of code that I have seen follows the simple schema presented above. And there are not many reasons, if any, for you not to follow it as well. I follow this pattern 99% of the time (and would encourage you to do the same), but there are also some cases where I renounce it. Two of them are described below.
Splitting Up Long Test Classes
When a test class starts to grow beyond the "safety limit" I have established for myself, I start to wonder whether splitting it up would not perhaps be a good idea. A common scenario, when I do split a test class up, is that there is a lot of arguments checking and numerous tests for expected exceptions. I usually move these tests to a separate class and use a different suffix - WrongValuesTest - to distinguish it. In the case of an exemplary MyClass, I would end up with the following test classes:
1. MyClassTest - all tests that puts the "valid" behaviour of the class through its paces. This test class shows the right way to use MyClass.
2. MyClassWrongValuesTest - all tests that put the SUT through its paces and fail (fast!) with an expected exception. This test class shows what happens when MyClass is used in an incorrect way.
The second test class - MyClassWrongValuesTest - is usually much simpler (but sometimes longer) than MyClassTest. Often it will contain some data providers, whose role is to provide various illegal values for different test methods. Test doubles are rarely required there (except, maybe, for dummies); this is because no methods are really called on them, as arguments checking is usually the first thing you do.
The necessity of splitting up a test class might by indicative that what you should really be splitting up is the class being tested itself! If it cannot be tested with one test class, maybe it is too big - maybe it has too much responsibility? If so, then fix this problem, and the test class will automatically shrink to an appropriate length.
Test Class Per Feature
Another way to go with test class naming is to base their name not only on a tested class, but also on a tested feature. The following story illustrates the usability of such an approach.
One day I was asked to introduce a change to a certain legacy code class called DataProvider. This class was responsible for some computations and offered some methods which returned the mean values of some calculated numbers. The then current implementation was to return null if some data required
1One that I am aware of, derived from the BDD approach, makes the test class name part of a "when" element of a BDD convention - see http://www.slideshare.net/wakaleo/junit-kung-fu-getting-more-out-of-your-unit-tests
192