Named unittests
Adam D. Ruppe
destructionator at gmail.com
Sat May 18 17:49:18 UTC 2019
On Saturday, 18 May 2019 at 14:56:16 UTC, Andrei Alexandrescu
wrote:
> Doesn't that seem a bit much? It seems to me you either want to
> run unittests or not, why run just a few?
The others already mentioned that this is a common pain point
among D users with third party code being included, but even with
your own code, there might be times when you'll want to take
shortcuts for a quicker test iteration cycle. Unittests are
supposed to be independent, after all, so no point running
hundreds of them when you are in the middle of working on fixing
just one.
This specific -unittest=pattern syntax has been requested a
couple times before, and there was at least one PR for it a
couple years ago. Here it is:
https://github.com/dlang/dmd/pull/6375
One of the suggestions back then was to make -unittest only work
on modules explicitly compiled in (open question: how does this
interact with the new -i switch added in 2018, after that 2017
PR?), but Atila said that breaks the utility
__traits(getUnitTests). You (Andrei) at the time said that is a
good trade off, and a few agreed.
I lean toward that being a good solution too, just Atila's
unit-threaded is an important project that we should give careful
consideration to when changing anything about D's unittest
facilities.
Another possibility is to compile in all the code, and use a
runtime switch to the program (instead of the compiler) to
determine which ones actually run. But I'd prefer doing it on the
compiler side because fast build times are one of D's key
advantages. Again, very frustrating to have to wait several
seconds each edit/build/debug iteration when you are working on
fixing one unit test at a time.
More information about the Digitalmars-d
mailing list