Tests vs. Specifications/Requirements OpenSpace
=====================================

Goals of Tests/Examples:
----
Express the details of requirements without obscuring the requirement with the
details.
* Many tests for each requirement
* (Boths levels of abstraction are important.)
Discover contradictions between requirements early.
* Turning into tests/examples is a form of feedback (on quality of requirements)
loop.
Discover gaps in the requirements early.
* Ditto
Record the results of discussion between business & development in a form both
can understand and which is self-verifying.
* Need to drive the incremental cost of recording the zeros to be less than the
percieved value derived from having the recording

self-verifying.
Specify potentially technology-specific requirements

Additional secondary goals:
------
Executable regression tests.
Change detector.
Measurement of progress towards "done".
Measurement of complexity of requirements.

Tests vs. Examples:
---------
Assertion: Examples describe vs. Tests Evaluate or Assess.
Examples can be used as tests.
Not all tests can be expressed as examples. That is, some tests describe a
procedure to execute. E.g. Do X for Y minutes, then do Z for

..., etc. then, ... . [Especially when there is some randomness to be
introduced.]

Rule: Anything over $5 gets a 10% discount.
Examples (& tests):
$5.00 gets no discount
$5.01 get $0.50 discount

A test that is not an example:
Run the system over the weekend with 10,000 calls per hour. On monday morning,
check for call dumps and memory leaks.
* There is no way this can be turned into an example because we don't know what
combination of steps will result in a problem.

This discussion was continued in the OpenSpace on Tests vs. Examples.