Olof-Joachim Frahm olof@macrolet.net writes:

Hi all,

I've looked through the open issues on Github and would like to get some input on a possible change/fix for issue #1, IN-SUITE* semantics:

A patch would be at [1], but I'm not sure this is the way to go. The change is to modify IN-SUITE*, so that it updates the existing suite if possible.

That was not quite straight forward as I'd hoped, in particular, the use of *SUITE* as the default value for :IN is a bit dangerous in this situation, because without checking for that case, one can quite easily create a loop from the updated suite to its parent, that is: itself, if the form is evaluated multiple times.

oh, that is confusing...

So now I'm checking for that, but really, isn't T as the default parent better? Updating would be really easy that way. Anyway, a testcase of the expected(?) behaviour is included. Of course deprecating IN-SUITE* (in favour of DEF-SUITE*?) would fix this, but keeping defined tests alive is a nice feature as well. (Also, it doesn't seem to be used all that often - on my system only elephant had some calls; admittedly grepping all quicklisp packages to get more information would be nice.)

so, i went ahead and grepped every .lisp file in the current quicklisp for in-suite*, and elephant is the only package that uses it (lparallel imports it, but doesn't actually use it) is in fact elephant. (def-suite* isn't used by anyone at all, not even fiveam or eos...)

however, when elephant does use in-suite* the :in argument is passed explicitly (so, in the one case where the user does want automatic reification of suites, they've also given enough information to make it independant of the current value of *suite*.

so, in practice, it doesn't matter.

now, I'd like to know if there's a simpler way to go about this.[1]

at the moment, i can't really see what purpose in-suite* could serve that def-suite* doesn't take care of (or what def-suite* does that in-suite* does). is there a reason to have both? and, given the difference between this:

(def-suite :foo :in :bar) (in-suite :foo)

and this:

(in-suite* :foo :in :bar)

i'm almost inclined to drop both of them (especially if it makes the code and the explanation of the code simpler).

Other than that, issue #3, named lambdas is already fixed, right? As far as I can tell there's no way to force any more information into the backtrace and NAMED-LAMBDA is already used, so the backtrace actually contains enough hints about the involved test case.

i think so too.

1 - afacit def-suite and in-suite don't have any problems of this sort: def-suite has all the arguments passed explicitly and *suite* does nothing. in-suite is also easy enough, the arguments are again passed explicitly and it just overwrites *suite* (and isn't effected by the current value of *suite*).