How can one reliably run unittests

[jfondren]

On Thursday, 2 September 2021 at 18:35:48 UTC, deadalnix wrote:
> The fact is that all the functionality that are desired to do 
> something sensible exist. There is just no way to plug them 
> into each other in any sensible way because all the utilities 
> and flags provided do some weird shit that is kinda useful but 
> not really.

The fact is that dmd is a compiler and not a build system. It 
therefore has flags that have simple, dumb, easy to compose 
behaviors rather than too-smart ones that would ever entertain 
considerations like "There is NO MAIN there is NO EXPECTATION 
THAT ANY MAIN IS RUN so ---" or "who would ever want what this 
combination of flags clearly does?"

When you pass -main, dmd adds a module to your build that 
includes a main function, job done. When you pass -unittest, dmd 
compiles in unittests and (as of recent versions) even has a 
somewhat nice default testing framework that provides feedback 
and skips running main(). When you pass --version, dmd prints out 
the version number without even asking if the commandline also 
asked for other stuff to be done.

The alternative to simple dumb flags is not a paradise where dmd 
always does what everyone expects; it's its own confusing hell 
where people are constantly surprised by behaviors that are too 
complex for the outcome to ever be predicted without a week-long 
course, instead of a quick check of the current manpage where 
each flag only needs a single sentence for a description.

I think there's an argument to be made that maybe a 'dmd test' 
should be added to run the tests of a single module. This 
wouldn't make anything easy that wasn't easy already, but it's a 
defensible bit of streamlining and it'd support one of D's 
advantages as a language. I think the very first complaint that 
someone would raise about it, in all caps, is that the use case 
of "dmd test a; dmd test b; dmd test c" would incur a lot of 
recompilation when these modules depend on each other, e.g. c 
might be built twice without unit tests and then a third time 
with them.