[fiveam-devel] Github issues, IN-SUITE* semantics

[Marco Baringer]

Olof-Joachim Frahm <olof at 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*).

-- 
-marco