A Proposal for

		       Porting the Common Lisp Test Suite

				      - - -

				  [Proposal #5]

				  Sept. 23, 1988 

			       David M. J. Saslav

				      - - -

Introduction:

	A significant portion of Common LISP functionality is not tested by the
	existing Common LISP regression test suite (found in SYS:VALID;).  This
	suite is run whenever a new system has been compiled.

Proposal:

	Part I:

	Spend one day or so surveying the test suite to determine which
	functionality is without test/validation sequences, attaching
	programmer-time	estimates for each major category of tests not
	currently in existence. (Already underway)

	Part II:

        Write test/validation regression tests for that portion of overall
	CommonLISP functionality not currently covered by the existing Common
	LISP test suite.

Rationale: 

In our case, the phrase "regression" has an important meaning: we must
ensure that the Falcon software is at least as good as, if not better
than, the existing Lambda system.  The existing test suite is the
starting point for a robust Common LISP regression suite, one which will
be usable over the entire lifetime of all future projects.

The existing test suite is healthy.  When first brought up on the
Lambda, it diagnostically located over twenty bugs as well as numerous
examples of anomalous behaviour requiring documentation.

The test suite needs immediate expanding, however.  If the first
comprehensive test of the complete Falcon system occurs after most (or
all) of the modules have been ported, newly-introduced problems will
take the maximum possible toll on developer time.  Full testing of the
core software gives an early indication of the scope and nature of
newly-introduced problems, thus minimizing the time required to solve
them.

While this kind of testing is supplemental to the testing that every
developer is responsible for within the particular development domain,
this regression suite should serve as a collecting place for these
tests.  They can be run every time the system changes substantially
(e.g., when the system is recompiled).  That is the meaning of the
phrase "regression" -- these tests are designed primarily to ensure that
the state of the software does not "regress", i.e., that the existing
software base never suffers damage from any major system development.

-keith/dmjs