Test Cases

"It is a very grave mistake to think that the enjoyment of seeing and searching can be promoted by means of coercion and a sense of duty."
Albert Einstein

What is a test case?

One of the major issues in testing is that the vocabulary is descriptive, but not standard. Many people would agree that a test case is a single testing action against the object under test. TET, however, calls this a test purpose.

If the test is automated, a test is an executable and its supporting files required to perform one or more test cases.

A generic automated test for an API might include

• a test.c file
• a make file
• one or more gold files for comparison

A generic automated test for a command line tool might include

• a test script (shell, perl, expect, tcl)
• one or more gold files for comparison

What makes a test case good?

Things that affect the quality of the tests:

• figuring out what qualifies as "interesting".
  Because there will never be enough time to fully test any non-trivial application, testers must concentrate on "interesting" conditions. Developers can be a big help in figuring out what this means.
• ability to create test conditions.
  Even if you know what you want to do, it may be difficult to create conditions that would exhibit problems.
• result checking.
  More is not necessarily better. Testers need to keep an eye on test execution time and provide testing in units of an hour or less. If the test can't be run in an hour, it will be run less frequently. In a hardware environment, this is especially critical because the speed difference between the simulation and real hardware environments is several orders of magnitude.
• isolation of errors.
  The way a test is written greatly affects how useful it is in debugging. If you can, write your tests so that the first test checks something simple, the next test builds upon that and so on. During debugging, you can then assert that if test 1 tests X, then test 2 is not failing because of X.

Copyright 1998 Anne Powell