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