Interesting, congrats. A common question that will come up is
comparing, contrasting, and integrating your work with the
existing unittest language feature. You may want to address
these issues directly in the documentation.
Thanks!! I'll put it in the doc (and also clean up my crude
documentation formatting). I plan to keep improving dunit too.
To answer quickly:
* The convenience couple of assertEquals() that I defined,
do work by throwing core.exception.AssertError. This means that
they
can be used inside the classic unittest{} blocks, if you
import dunit.
* The classic assert() statement can be used inside DUnit tests.
* One could run DUnit tests when passing -unittest to dmd.
Just define once somewhere in your project:
unittest {
import dunit;
dunit.runTests();
}
And all the classes in your project that are marked as DUnit
tests
with mixin TestMixin; will get run, no matter which module
they are in.
* DUnit also shows exceptions which are not asserts. Those are
displayed as 'Errors' instead of 'Failures' (as the java style).
* DUnit will not halt the execution of the program if a test
fails.
It will keep going with the next test. This is very useful when
combined with:
unittest {
import dunit;
dunit.runTests();
}
On the other hand, D's classic unittests would halt the
execution
at the first failure.
* D's classic unittest{} blocks are more straightforward and
instantaneous to learn, and support a brief style of writing
unit tests that DUnit is not meant for.
* DUnit provides a style of unit testing popularized in the OOP
crowd
which begun with sUnit by Kent Beck (smalltalk), later jUnit by
Kent Beck
and Erich Gamma (java), and then also NUnit for .NET (there
also exists
too FlexUnit for Flex, FireUnit for Javascript, CppUnit for C++
etc., but
those deviate a little from the originals).
So DUnit brings D to the familiy of languages that support
certain
testing idioms familiar to many OOP developers. (tests fixtures
(grouped by
classes), with common initialization, green bars ;-), decoupled
test runners,
convenience assert functions, etc.
(I'm thinking of writing a quick DWT GUI test runner too
# (OFFTOPIC: I made a patched DWT that works in linux 64bits (by
fixing
a few bugs and commenting out some impossible XPCOM code
and I'll try to sync to Jacob Carlborg's github repo
when I have more time; and fixed missing 'double vars=0' inits
instead of
NaN that produced slowdowns and prevented certain drawing
functions
from working in the Graphics Context)).
--jm
On Sunday, 19 February 2012 at 16:36:53 UTC, Andrei Alexandrescu
wrote:
On 2/19/12 9:30 AM, Juan Manuel Cabo wrote:
People of the D world.. I give you DUnit (not to be confused
with an old
tango DUnit, this one is for >= D2.057, and doesn't really
require
phobos or tango (just you version the few writeln's of the
runner, and
maybe
something else)).
https://github.com/jmcabo/dunit
Interesting, congrats. A common question that will come up is
comparing, contrasting, and integrating your work with the
existing unittest language feature. You may want to address
these issues directly in the documentation.
Thanks,
Andrei
