Open jorams opened 8 years ago
@jorams a simpler way might be to have 1am:test
associate tests with the current *package*
(e.g., by turning 1am:*tests*
into an hash-table mapping package names to lists of tests) and add the ability for 1am:run
to filter by package and perhaps default to the current *package*
. What do you think?
If I want to use vanilla 1AM, I use a very simple 1AM wrapper to achieve multiple test suites.
(defvar *my-tests* '())
(defun run ()
(1am:run *my-tests*))
(defmacro define-test (name &body body)
`(let ((1am:*tests* '()))
(1am:test ,name ,@body)
(pushnew ',name *my-tests*)))
Likewise, I'd suggest 2AM. https://gitlab.common-lisp.net/dkochmanski/2am
I'm really liking 1am for its simplicity, but I think one addition could be very nice.
Right now, every test defined ends up in one big list. If different systems want to use 1am and not interfere with other systems, they copy the file into their project and change the package name. That workflow is simple and works well, but a bit more code reuse is, I think, desirable. To achieve that, there needs to be some way to differentiate collections of tests, or "test suites".
For a project I'm working on, I wanted different collections of tests even in the same system. I wrote a quick macro to facilitate that,
DEFINE-TEST-FRAMEWORK
. A package containing a test suite then only importsIS
andSIGNALS
from 1am, and contains a form like this:The newly defined
MY-TEST
macro is then used to define new tests, and they are run using the newMY-RUN
function. Different test "frameworks", as I called them here, don't interfere with eachother.I think including something similar to this directly in 1am would be a good idea. Any thoughts?
The macro I whipped up: