Junit Test Practices
Now that we've seen JUnit in action, let's step back a little and look at some good practices for writing tests. Although we'll discuss implementing them with JUnit, these practices are applicable to whatever test tool we may choose to use.
Write Tests to Interfaces
Wherever possible, write tests to interfaces, rather than classes. It's good OO design practice to program to interfaces, rather than classes, and testing should reflect this. Different test suites can easily be created to run the same tests against implementations of an interface (see Inheritance and Testing later).
對(duì)某個(gè)類進(jìn)行測(cè)試時(shí)，僅測(cè)試該類對(duì)外公開(kāi)的接口，適當(dāng)?shù)臏y(cè)一些其內(nèi)部的接口。當(dāng)一個(gè)類從其他類繼承方法時(shí)，那么對(duì)這些方法的測(cè)試則不應(yīng)該由subclass的測(cè)試完成，而由parent class的測(cè)試完成。
Don't Bother Testing JavaBean Properties
It's usually unnecessary to test property getters and setters. It's usually a waste of time to develop such tests. Also, bloating test cases with code that isn't really useful makes them harder to read and maintain.
Maximizing Test Coverage
Test-first development is the best strategy for ensuring that we maximize test coverage. However, sometimes tools can help to verify that we have met our goals for test coverage. For example, a profiling tool such as Sitraka'sJProbe Profiler (discussed in Chapter 15) can be used to examine the execution path through an application under test and establish what code was (and wasn't) executed. Specialized tools such as JProbe Coverage (also part of theJProbe Suite) make this much easier. Jprobe Coverage can analyze one or more test runs along with the application codebase, to produce a list of methods| and even lines of source code that weren't executed. The modest investment in such a tool is likely to be worthwhile when it's necessary to implement a test suite for code that doesn't already have one.
Don't Rely on the Ordering of Test Cases
When using reflection to identify test methods to execute, JUnit does not guarantee the order in which it runs tests. Thus tests shouldn't rely on other tests having been executed previously. If ordering is vital, it's possible f to add tests to a TestSuite object programmatically. They will be executed in the order in which they were added. However, it's best to avoid ordering issues by using the setup () method appropriately.
Avoid Side Effects
For the same reasons, it's important to avoid side effects when testing. A side effect occurs when one test changes the state of the system being tested in a way that may affect subsequent tests. Changes to persistent data in a database are also potential side effects.
Read Test Data from the Classpath, Not the File System
It's essential that tests are easy to run. A minimum of configuration should be required. A common cause of problems when running a test suite is for tests to read their configuration from the file system. Using absolute file paths will cause problems when code is checked out to a different location; different file location and path conventions (such as \home\rodj \tests\foo.dat or C:\\Documents and Settings\ \rodj \ \ f oo.dat) can tie tests to a particular operating system. These problems can be avoided by loading test data from the classpath, with the Class.getResource () or Class.getResourceAsStream() methods. The necessary resources are usually best placed in the same directory as the test classes that use them.
Avoid Code Duplication in Test Cases
Test cases are an important part of the application. As with application code, the more code duplication they contain, the more likely they are to contain errors. The more code test cases contain the more of a chore they are to write and the less likely it is that they will be written. Avoid this problem by a small investment in test infrastructure. We've already seen the use of a private method by several test cases, which greatly simplifies the test methods using it.
Inheritance and Testing
We need to consider the implications of the inheritance hierarchy of classes we test. A class should pass all tests associated with its superclasses and the interfaces it implements. This is a corollary of the "Liskov Substitution Principle", which we'll meet in Chapter 4.
When using JUnit, we can use inheritance to our advantage. When one JUnit test case extends another (rather than extending junit.framework.TestCase directly), all the tests in the superclass are executed, as well as tests added in the subclass. This means that JUnit test cases can use an inheritance hierarchy paralleling the concrete inheritance hierarchy of the classes being tested.
In another use of inheritance among test cases, when a test case is written against an interface, we can make the test case abstract, and test individual implementations in concrete subclasses. The abstract superclass can declare a protected abstract method returning the actual object to be tested, forcing subclasses to implement it.
It's good practice to subclass a more general JUnit test case to add new tests for a subclass of an
object or a particular implementation of an interface.