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