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
