About GroboUtils

• Welcome
• License
• Project List
• Contacts
• Articles

Sourceforge
Project

• Forums
• Bugs
• Feature Requests

For Developers

• Downloads
• Javadoc
• Dependencies
• Building

GroboTestingJUnit version 1.2.1

Author:Matt Albrecht

I've Never Heard Of That Before

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.

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 java.util.StringTokenizer that changed between JDKs. JRun version 3 fixed the problem, but it shows a major deficiency in testing.

I have elsewhere defined Integration Unit Tests, 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".

That's Odd

"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 [BG99] imply that in object-oriented programs, the logic of the design moves from the functions to the structure 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.

One Man's Trash Is Another Man's Enemy Unit Test

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?

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.

References