DUnit - class MyTest { mixin TestMixin; void testMethod1() {} void testMethod2() {}}

[Juan Manuel Cabo]

> 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