Testing and verification


You may choose your own format for test input.  Be sure that you document such decisions:  your reasons for your choices over others, and any significant/relevant side-effects of your choices.  Efficiency is the primary consideration, but ease and clarity of coding should not be overlooked.  Document and justify all of your decisions.

The main concern is that your algorithms (sorts, multipliers, etc.) should be independent of the source of data, timing routines, debugging, testing routines, I/O, etc.  I should be able to take your code for the function(s) that perform some job and use your code without having your routines waste space copying the input (unless the algorithm requires it), waste time performing timing operations, or produce annoying debugging or testing printouts.  All of these tasks should be performed by your testing functions before and after calling the lab function, for whatever algorithm is being tested.  Obviously this means that the functions should not be passed anything but what they need to do the job they are written for:  not structures to record testing information or switches for testing-related control.  The set of functions that perform a task may share global data if you find it absolutely necessary, but should not share any global data with the other portions of your lab (I/O, testing, etc.).

It is not sufficient to state that there are no error conditions just because your testing functions always generate correct tests.  Your functions should do something reasonable if the data passed to them cannot be processed properly.  You may even want to have your tester throw some errors at your functions to demonstrate their reactions.  Possible errors include (but are not necessarily limited to) having a negative dimension passed as a parameter, getting an illegal result during arithmetic calculation (such as overflow), or being unable to allocate scratch memory needed.  If you read from a file, you should be able to gracefully handle errors related to file access.

The output of your program should not contain lengthy "dumps" of all variables evaluated by the various functions in your program.  Instead, your test procedures should call your functions and then use a simple (and possibly slower) method of verifying the accuracy of your results.  Thus, the only output (other than statistics) should be short indications from the test procedure that your inner project procedures are working correctly.  I should have to check only the correctness of your test procedures in order to be convinced of the correctness of your lab.


In the simplest sense, verification means demonstrating that your program works.  Verification runs should show that subroutines, subparts, and the final product work.  These runs must show that:

Verification runs should include:

Dan Hirschberg
Computer Science Department
University of California, Irvine, CA 92697-3435
dan (at) ics.uci.edu
Last modified: Mar 22, 1999