On 2013-09-23 18:40, jostly wrote:

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.

Agree. I only see the unittest blocks as a place to but the asserts, since it's not possible to put them at module level.

It's possible to implement you're own unit test handler. See:


It's also possibly to set the assert handler:


But you most likely want to throw some kind of exception anyway. Because if an assertion is triggered in a unit test block you most likely want to end that unit test block, immediately.

/Jacob Carlborg

Reply via email to