TODO

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