TODO

   1 (1) A documentation of the internals would be useful.
   2
   3 (2) Add unit testing for lisp-unit. I think the approach should be to
   4     note some functions and macros as identities that have be verified
   5     or are logically correct. All tests of lisp-unit should then be
   6     defined in terms of the identity functions. Maybe a core set of
   7     functionality should be verified using standard CL comparisons
   8     such as eq, eql, =, etc.
   9
  10 (3) Fixtures
  11
  12 (4) Test Suites
  13
  14 (5) Generate a tutorial describing how to use LISP-UNIT.
  15
  16 (6) Improve the test report. Initially, it would be useful to only
  17     specifically report the failures and otherwise just report the
  18     overall summary. Other improvements might be some sort of progress
  19     indication, like 'PPPPFPPPFFFP.......' where P is pass, F is fail
  20     and (.) is not performed yet. Ideas here are welcome.
  21
  22 (7) Design better data structures for the sequence and array error
  23     results. The data structure is currently a nested list. Should
  24     probably be a structure or class. Maybe a hash table.
  25
  26 (8) Better integrate the numeric diagnostic functions with the numeric
  27     assertions. Currently, the VALUE and FORM argument of the
  28     assertion must be repeated as arguments to the diagnostic
  29     function. The intent is that you simply note the diagnostic
  30     function that you wish to apply to the test in the event of a
  31     failure and the VALUE and FORM arguments are automagically passed
  32     to that function.
  33
  34 (9) Interactive correction of tests. Something along the lines of the
  35     debugger, maybe actually using the debugger. I envision a
  36     work-flow scenario where you run all of the tests and see X of Y
  37     tests failed. Now you enter a form like
  38
  39     CL-USER> (lisp-unit:run-failed-tests :interactive t)
  40
  41     where the default for interactive is nil. Actually, this approach
  42     could also satisfy the reporting requirements. Anyway, the first
  43     failed test is executed reporting the results and you are provided
  44     a prompt with some options. The options could be along the lines
  45     of abort the testing, pick a diagnostic function to execute or
  46     re-run the test. If the re-run the test option is chosen, it
  47     should be after modifications to the definition of the test or the
  48     routine being tested are made. The idea for this interactive
  49     correction feature is to tighten the debug loop. Input on this
  50     idea is highly welcome.
  51
  52 (*) Benchmarking