On Saturday, 6 August 2016 at 01:50:15 UTC, Øivind wrote:
On Friday, 5 August 2016 at 15:31:34 UTC, Atila Neves wrote:

What's new:
. Mocking support. Classes, interfaces and structs can be mocked (see README.md or examples) . Shrinking support for property-based testing, but only for integrals and arrays
. Bug fixes




I have started using unit_threaded, and love it.

The other day, I was thinking about how to run tests optimally. Not sure if you are doing this at the moment.

For every test-run, you could record the time each individual test takes. You could then give two options for running the tests:
1) Fast tests first, to quickly see if things look ok
2) Slow tests first, trying to optimize total runtime

Test-times would have to be recorded in a file between runs in order to achieve this. Would also be nice to print the time used by each test next to the tests.


In my case, unit tests are fast by definition. If I use unit-threaded for integration tests (which I've done), then those are in a separate package and I can just select which tests to run that way. If organising by package is too much hassle, you can tag tests now as well:

@Tags("slow") unittest { ... }

And then don't run those with the `~@slow` command-line option.


Reply via email to