Test Cases - A testcase starts from a base state
QA department might use the term baseline to refer to this expected
state.) This stage is the heart of the testcase.
undoing the steps performed in stage 1.
independent
undo this setup in stage 3, so that the testcase can be executed independently
of every other testcase. In other words, the testcase should not rely upon the
successful or unsuccessful completion of another testcase, and the order in
which it is executed should have no bearing on its outcome.
error causes the setup to fail or, worse yet, the application to crash, all
subsequent testcases will fail because they cannot achieve the state where the
test is designed to begin.
single purpose
stage 2. When a testcase designed in this manner passes or fails, it's easy to
determine specifically what aspect of the target application is either working
or not working.
Therefore, an exception may not point specifically to a single failure in the
software under test but rather to several related function points. This makes
debugging more difficult and time-consuming and leads to confusion in
interpreting and quantifying results. The net result is an overall lack of
confidence in any statistics that might be generated.
verification in a testcase. See "Performing more than one verification
in a testcase" on page 211.
a base state
in a stable state when the testcase begins to execute. This stable state is called
the base state. The recovery system is responsible for maintaining the base
state in the event the application fails or crashes, either during a testcase's
execution or between testcases.
system contains a routine called DefaultBaseState that makes sure that