Why write programs in Common Lisp but tests like Java? Meet CheckL!
Common Lisp CSS
Latest commit 866f3d7 Sep 16, 2014 @rpav *print-circle*
Failed to load latest commit information.
doc VALUES -> RESULTS May 8, 2012
t Import Apr 26, 2012
README.md Deep copy results; documentation May 7, 2012
checkl-docs.asd Documentation May 7, 2012
checkl.asd Import Apr 26, 2012
checkl.lisp *print-circle* Sep 16, 2014
formalize.lisp Refer to the correct OPERATE symbol Aug 31, 2012
package.lisp VALUES -> RESULTS May 8, 2012



Why write programs in Common Lisp but tests like Java?

My workflow for writing Common Lisp tends to be like this:

  • Write a bit of lisp, perhaps a function, class, or structure
  • Write a snippet in a scratch buffer to test
  • Fix if necessary and repeat

Testing is already inherent in this process, all we need is a little bit of Common Lisp magic to take advantage of it. Thus, CheckL:

(defun foo ()
  (+ 1 1))

(check () (foo)) ;; => 2

(defun foo ()
  (+ 1 2))

(check () (foo))


Result 0 has changed: 3
Previous result: 2
   [Condition of type CHECKL::RESULT-ERROR]

 0: [USE-NEW-VALUE] The new value is correct, use it from now on.
 1: [SKIP-TEST] Skip this, leaving the old value, but continue testing
 2: [RETRY] Retry SLIME interactive evaluation request.
 3: [*ABORT] Return to SLIME's top level.
 4: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" RUNNING {100586AB13}>)

See the full documentation for more details!