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
63
64
65
66
67
68
69
70
71
72
73
74
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<document>
<head>
<name>Enemy Unit Tests</name>
<doc-version>$Date: 2003/05/04 06:40:13 $</doc-version>
<author>Matt Albrecht</author>
</head>
<body>
<section>I've Never Heard Of That Before</section>
<P>
I've noticed that some projects depend on third-party packages, and an upgrade
to the third-party package breaks the project's operation. In some cases,
this can be inter-project dependencies. If the QA department is good, then
these issues will be flushed out in integration tests. In other cases, a
developer simply misunderstands what a foreign "unit" was designed to do,
whether this is due to poor documentation or ignorance.
</P>
<P>
As an example,
Alaire's JRun version 2.3.3 worked just fine with JDK 1.2. However, when
JRun was run with JDK 1.3, it broke due to a dependency on a functionality
in <tt>java.util.StringTokenizer</tt> that changed between JDKs. JRun version
3 fixed the problem, but it shows a major deficiency in testing.
</P>
<P>
I have elsewhere defined <link href="art_iut">Integration Unit Tests</link>,
but this covers the testing the interactions of "units" (or in Java terms,
classes) which depend upon one another. The QA team's integration tests
may occur too late in the development process, and the cost of fixing such
bugs at that time may be very expensive. I have identified here an
opportunity for unit tests that ensure that the developer has a correct
understanding of what she's interfacing with, and that those units don't
change their functionality over time. I call these tests "enemy unit tests".
</P>
<section>That's Odd</section>
<P>
"Enemy" unit tests? I haven't really heard from research groups any kind of
reference to tests that lie in this muddled-land. However, texts such as
<ref name="BG99" /> imply that in object-oriented programs, the logic of the
design moves from the functions to the <i>structure</i> of the objects.
In a way, these tests could be considered a kind of integration tests,
sometimes referred to as dependency tests. I find it more useful to call them
enemy tests, since it brings across the idea that these dependent units
aren't dependable, unless we assert that they can be relied upon.
</P>
<section>One Man's Trash Is Another Man's Enemy Unit Test</section>
<P>
What about the dependent unit's unit tests? If we assume (or assert) that
the dependent unit has sufficient unit tests, then why do enemy tests?
</P>
<P>
For one thing, EUTs are a good place to experiment with an unknown API. A
common developer's activity is to code directly for the API in the project
source, and write unit tests to ensure that the project code is doing the
right thing. I have found it easier to write "throw-away" Java classes to
test out an API, to make sure that I know what I'm doing before actually
codifying the project. EUTs are a good place to put this experimental code.
Later, you can build on these tests to robustly ensure that what you expect
from an API actually occurs.
</P>
<reflist>
<refitem id="BG99">
Imran Bashir and Amrit L. Goel. <i>Testing Object-Oriented Software:
Life Cycle Solutions.</i> Springer, 1999.
</refitem>
</reflist>
</body>
</document>
|
