How can one reliably run unittests

Mathias LANG geod24 at gmail.com
Fri Aug 27 07:48:40 UTC 2021


On Friday, 27 August 2021 at 00:44:03 UTC, Steven Schveighoffer 
wrote:
>
> unittesting code is in the binary whether unittests are run or 
> not. Whether unittests should be run is all decided at runtime.

And that is the root of the problem. Very few people expect or 
want this.
Let's just make `-unittest` its own, separate compilation mode, 
with a different entry point, like it should have been done 15 
years ago.

> But also, what I meant is, if you are going to include all the 
> parts to colorize things, that now needs to be part of druntime.

Considering the above is fixed, this isn't a problem anymore. 
Either via `--gc-sections` or similar, or simply by making it a 
compiler-instantiated template.

> This is different, because the language doesn't have to include 
> the framework to do it. You can write this separately.

I like that D allows me to do pretty much anything the way I want 
it. I can override operators to the extent that I can event 
replicate the special case that is associative array first 
assignment. That's pure, plain amazing. And it comes without 
bloat. No runtime indirection, things are "pay-as-you-go".

But when I throw in the `-unittest` switch (or the `-cov` or 
`-profile` for that matter), I want all the bells and whistles. 
Give me colors, an ncurses interface, an HTTP server even! Give 
me the full battery pack. Don't expect everyone and their mother 
to implement their own testing framework, that's just bonkers.


More information about the Digitalmars-d mailing list