Redefining Test Terminology

So, earlier I mentioned Mock Objects — The TDD variant that requires isolation of the tested component. The Mock Objects technique requires a hierarchy of tests:

  1. At the lowest level, objects are tested in isolation against mocks.
  2. Higher up, objects are tested in collaboration with a few other real objects.
  3. Higher up, the entire system is tested.
  4. At the top level, test define if the system is complete.

That’s a good hierarchy. My only problem is with the names that they use.

Mock Object developers use these names:

  1. Unit
  2. Integration
  3. System
  4. Acceptance

Long before that, I head people use these names:

  1. “Why are you testing at such a low level? Don’t waste your time.”
  2. Unit
  3. “We probably ought to run the whole thing on some sample data.”
  4. Acceptance

On top of which, there are two other things called “Integration Tests”, which long predate Mock Objects:

QA Integration Tests: We’ve upgraded to the latest version of of GUI library. Let’s run some integration tests to make sure nothing broke. (Usually a full regression sweep.)

(Pre-Agile) Developer Integration Tests: We’re merging three new feature branches on Tuesday. We’d better do some testing to make sure they integrate properly.

At this stage of the game, it’s just not a good idea to re-use existing terms for different things. Especially when telling the difference between those things requires you to read the mind of the speaker.

Comments are closed.