DUnit: Advanced unit testing toolkit.

[jostly]

On Sunday, 22 September 2013 at 13:13:29 UTC, linkrope wrote:
> Have a look at https://github.com/linkrope/dunit, especially at
> the "Related Projects".
>
> Until now, my preferred tool for (large-scale) unit testing in D
> would be the combination of my dunit framework (of course),
> DMocks-revived for mocks, and the 'must' matchers of specd.

I think it's great to see the D unit testing ecosystem growing. 
Since it's still relatively small, I think we have a good chance 
here to create interoperability between the different frameworks.

As I see it, we have:

1. Running unit tests

This is where D shines with the builting facility for unit tests. 
However, it suffers a bit from the fact that, if we use assert, 
it will stop on the first assertion failure, and there is (as far 
as I've been able to tell) no reliable way to run specific code 
before or after all the unit tests. If I'm wrong on that 
assumption, please correct me, that would simplify the spec 
running for specd.

In specd, the actual code inside the unittest { } sections only 
collect results, and the reporting is called from a main() 
supplied by compiling with version "specrunner" set. I haven't 
checked to see if your dunit do something similar.

2. Asserting results

Varies from the builtin assert() to xUnit-like assertEquals() to 
the more verbose x.must.equal(y) used in specd.

This could easily be standardized by letting all custom asserts 
throw an AssertError, though I would prefer to use another 
exception that encapsulates the expected and actual result, to 
help with bridging to reporting.

3. Reporting results

If we have moved beyond basic assert() and use some kind of unit 
test runner, then we have the ability to report a summary of run 
tests, and which (and how many) failed.

This is one area where IDE integration would be very nice, and I 
would very much prefer it if the different unit test frameworks 
agreed on one standard unit test runner interface, so that the 
IDE integration problem becomes one of adapting each IDE to one 
runner interface, instead of adapting each framework to each IDE.

In my experience from the Java and Scala world, the last point is 
the biggest. Users expect to be able to run unit tests and see 
the report in whatever standard way their IDE has. In practice 
this most often means that various libraries pretend to be JUnit 
when it comes to running tests, because JUnit is supported by all 
IDEs.

Let's not end up in that situation, but rather work out a common 
API to run unit tests, and the D unit test community can be the 
envy of every other unit tester. :)