I don't think that this is in bugzilla, and I don't want to get lost, so I'm adding it.
Currently, if a unittest block fails in a module, no more unittest blocks in that module run. The unittest blocks in other modules are run, but not the rest of the unittest blocks in any module where a test failure occurs. Ideally, _every_ unittest block would run. Failures would be reported for each block which failed, but whether a particular unittest block failed would have no impact on whether the other unittest blocks ran.
There was a discussion on the Phobos list about this a few months back, and from this post ( http://www.mail-archive.com/[email protected]/msg01307.html ) by Sean Kelly, it appears that a change needs to be made to dmd to make this possible. So, whatever change needs to happen to dmd to properly expose the unittest blocks and make it possible to call all of them in a module even if one fails needs to be done one of these days (preferrably sooner rather than later).
Comment #1 by dmitry.olsh — 2018-05-22T09:12:25Z
Jonathan, do you customizable test runner that D currently has still not addresses this? Including ready-made cutomizations such as unit-threaded and friends on dub.
Comment #2 by issues.dlang — 2018-05-22T11:31:44Z
(In reply to Dmitry Olshansky from comment #1)
> Jonathan, do you customizable test runner that D currently has still not
> addresses this? Including ready-made cutomizations such as unit-threaded and
> friends on dub.
Personally, I only ever use the built-in test runners, and I have no clue what improvements have been made since I reported this (though I'm sure that the behavior for the default test runner is the same). Based on what I've seen Atila say about unit-threaded, I _think_ it's the case that he's able to use __traits(getUnittests, ...) (or something like that anyway) to access each unittest block directly and run it, in which case, presumably means that he can make it run any combination of tests he wants, but I don't know. I'm fairly certain that ___traits bit that he uses didn't exist when this was reported.
If other test runners can indeed run all of the tests in a module now, then there really isn't any reason to leave this open, but the default test runner has worked well enough for me that I haven't bothered to mess with others, so I don't know what they can or can't do in this regard.
Comment #3 by robert.schadek — 2024-12-13T17:54:23Z