Unit Testing in Action

[Atila Neves]

On Friday, 20 October 2017 at 14:04:25 UTC, Mike Parker wrote:
> After a couple of weeks of quiet on the D blog, it's about to 
> get noisy again. The latest is is a post by Mario Kröplin of 
> Funkwerk describing how the company now uses D's built-in tests 
> in their codebase after several years of using third-party 
> frameworks.
>
> Blog:
> https://dlang.org/blog/2017/10/20/unit-testing-in-action/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/77m8r8/ds_builtin_unit_testing_in_action/

"Only for troubleshooting should you switch to unit-threaded. You 
have to be careful, however, to only use compatible features."

I probably should have made it more widely known that 
unit-threaded now has a `unitThreadedLight` version geared 
towards fast compile times. It uses the default test runner you 
get normally with just `-unittest`, but implements all of the 
custom assertions as plain asserts for faster turnaround times 
when the tests pass.

"parallel test execution (from it’s name, the main goal of 
unit-threaded) was quite problematic with the first test suite we 
converted"

I'd love to know what the problems were, especially since it's 
possible to run in just one thread with a command-line option, or 
to use UDAs to run certain tests in a module in the same thread 
(sometimes one has to change global state, as much as that is 
usually not a good idea).

"With the new static foreach feature however, it is easy to 
implement parameterized tests without the support of a framework"

It is, but it's the same problem with plain asserts in terms of 
knowing what went wrong unless the parameterised value happens to 
be in the assertion. And there's also the issue of running the 
test only for the value/type that it failed for instead of going 
through the whole static foreach everytime.

Atila