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


Reply via email to