Unit Testing in Action

Mario Kröplin linkrope at github.com
Tue Oct 24 11:22:20 UTC 2017


On Monday, 23 October 2017 at 12:38:01 UTC, Atila Neves wrote:
> "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).

Delays are our business, so we use the clock and timers 
everywhere. Long ago, we introduced Singletons to be able to 
replace the implementations for unit testing. By now, lots of 
tests fake time and it's a problem if they do so in parallel. 
It's not too hard, however, to change this to thread-local 
replacements of the clock and timers.

Another problem was using the same port number for different test 
cases. We now apply "The port 0 trick" 
(https://www.dnorth.net/2012/03/17/the-port-0-trick/).

> "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.

That's why I recommend to put the `static foreach` around the 
`unitest`. My example shows how to instantiate test descriptions 
(with CTFE of `format`) so that these string attributes are used 
to report failures or to slectively execute a test in isolation.


More information about the Digitalmars-d-announce mailing list