Open Ambrevar opened 2 years ago
Which fork of Lisp-Unit2
should be preferred? Seems some are way beyond the 'official' one.
I'm using https://github.com/AccelerationNet/lisp-unit2 but I have no clue about the others.
EDIT: Fixed link.
I certainly think this is possible, and should not be too much work depending on the lisp-unit2's APIs. I'm happy to add it, but I want to make sure there's going to be a user and dog-fooder before I dive into it. @Ambrevar do you use lisp-unit2 on a regular basis?
(PS. Might not get to it in the next few days though)
I plan to transition https://github.com/atlas-engineer/nyxt/, https://github.com/atlas-engineer/nfiles and all the deps (3-4 of them for now) to it.
Update: we've fully switched to Lisp-Unit2 :)
@Ambrevar done, as of now you can run tests, rerun in debugger. Jump to test is not implemented for any CL implementation (in theory, that could be implemented for some CL implementations with some additional changes to lisp-unit2).
You just have to load slite/lisp-unit2
. I'm closing this task out for now, but let me know if things are working. I'd be particularly interested in edge cases with tests without any results, tests with only failures, tests with only errors, etc. I'll update the documentation later.
(actually keeping this open for now until I can get verification from you)
I'm not sure how lisp-unit2 is supposed to handle this case:
(unit:define-test error-test
(:tags '(bar))
(error "blah blah"))
run-tests
seems to not be handling the error. Is that how lisp-unit2 is supposed to work? Is there a better function than run-tests that I should be typically calling?
I think this is meant to be run from asdf:test-system
, which does the right thing here (that is, not prompt the debugger).
That said, if your question is how to test this specific test programmatically without triggering the debugger, then you can do:
(let ((*debugger-hook* nil))
(lisp-unit2:run-tests :name 'error-test
:run-contexts 'lisp-unit2:with-summary))
From the README:
Debugging is controlled by
*debugger-hook*
(as is usual in common-lisp). You can make lisp-unit simply record the error and move on by binding*debugger-hook*
to nil around yourrun-tests
call.
that's interesting. What behavior do you expect to see? My personal expectation when using slite is that when running tests the debugger should not show up unless I rerun the test with debugging enable. Would you say that is what you expect too? I could bind debugger-hook to nil if that's the case. (But that's not 100% correct, since it wouldn't hande any crashes from other threads)
I think that should be an easy change, just let me know if that would be your expected behavior
Actually I like that the debugger shows up when running individual tests: it gives me more information. If I only wanted a summary, I would run the whole test suite, right?
So for me it's fine as it is :)
@Ambrevar Just to be clear, slite has that mode. Essentially it runs all the tests, shows which tests failed, and you can press 'r' on the any test to run it with a debugger. So you can get best of both worlds. But in any case, play around with this for a while and let me know how you feel about it.
In my opinion (see https://github.com/atlas-engineer/nyxt/issues/2199#issuecomment-1146808213), Lisp-Unit2 is one of the best test framework for Common Lisp (together with Parachute). It would be great to add support for it in Slite.
It does not seem to be too hard since Lisp-Unit2 also reifies test results with a structure / class.
Also see my personal hack to implement "run test at point" for Lisp-Unit2: