1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<document>
<head>
<name>JUnit Patterns</name>
<doc-version>$Date: 2003/05/04 06:40:13 $</doc-version>
<author>Matt Albrecht</author>
</head>
<body>
<P>
Here's a list of problems presented during testing JUnit tests, and possible
set of solutions.
</P>
<H3>Subclass Anti-Pattern</H3>
<P>
A common technique in writing JUnit tests goes like this. The developer
writes a test that contains a lot of logic for a specific package. When
the developer moves to the next class in the package, she finds that the
same logic or data is shared between the two tests, so the tests are
refactored, creating an abstract superclass for both tests.
</P>
<P>
This subclassing pattern breaks down when some tests require the functionality
from two orthogonal functionality sets. Since Java does not support multiple
inheritance, the test must be split to artificially accomodate the two required
functionalities, which also may lead to some tests that use both
functionalities not being written.
</P>
<P>
Instead, a suite utility class can be written for the purpose of aiding in
tests. Not only does this break the tests away from the subclass anti-pattern,
but it also isolates code that can be useful for outside projects. In this
way, these utility classes can be moved from the tests to the production
code if they are considered very useful.
</P>
<H3>Testing Protected Code</H3>
<P>
A developer will want to test the functionality of a class's protected or
package-private members, and under most circumstances, this is not possible
without the use of "backdoor" code.
</P>
<P>
Tools such as the JUnitX package act as class loaders which change the
signature of classes under test so that the protected members can be accessed
by tests.
</P>
<P>
Instead, put tests in the same package as the class files. Now, tests can
access all outside accessible points of contact for assurance of correct
behavior.
</P>
<P>
See <link name="art_naming">Naming Your JUnit Tests</link> for more information
on this technique.
</P>
</body>
</document>
|
