The problem is the way that these macros handle their :in keyword argument (
|
(defmacro def-suite (name &key description in) |
):
(defmacro def-suite (name &key description in)
"Define a new test-suite named NAME.
IN (a symbol), if provided, causes this suite te be nested in the
suite named by IN. NB: This macro is built on top of make-suite,
as such it, like make-suite, will overrwrite any existing suite
named NAME."
`(eval-when (:compile-toplevel :load-toplevel :execute)
(make-suite ',name
,@(when description `(:description ,description))
,@(when in `(:in ',in)))
',name))
If you explicitly supply :in nil as a way to indicate that you want a top-level suite, the macro will simply discard it. To fix this, we need to have (in nil in-supplied-p) and we need to check in-supplied-p and not in in the when form.
I could make a merge request, but would like to know that it would be accepted (assuming it's a good MR) before bothering.
The problem is the way that these macros handle their
:inkeyword argument (fiveam/src/suite.lisp
Line 36 in 0c73f12
If you explicitly supply
:in nilas a way to indicate that you want a top-level suite, the macro will simply discard it. To fix this, we need to have(in nil in-supplied-p)and we need to checkin-supplied-pand notinin thewhenform.I could make a merge request, but would like to know that it would be accepted (assuming it's a good MR) before bothering.