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

[Juan Manuel Cabo]

On Wednesday, 21 March 2012 at 20:04:39 UTC, Rio wrote:
> On Wednesday, 21 March 2012 at 17:29:59 UTC, Juan Manuel Cabo
> wrote:
>> Btw, here is the whole list:
>>    
>> http://www.junit.org/junit/javadoc/3.8.1/junit/framework/Assert.html
>>
>>
>> Do you have any thoughts?
>
> Be careful: for JUnit 4 there is a separation of concerns.
>
> The assertions are now the responsibility of the Hamcrest
> library: http://code.google.com/p/hamcrest/
> (Wouldn't it be nice to have a port to D?)

Not true.
Regular asserts are still regular asserts in junit4.
Hamcrest is supported for other kinds of asserts.

The only care taken must be to consider an assert as something
that throws core.exception.AssertError, which is already done.
You can create your own kinds of asserts.

Also, for mock objects, take a look at BlackHole and WhiteHole
in std.typecons. That, together with anonymous classes pretty much
is all you need for basic mock objects for testing.


>
> On the other hand, D/JUnit "just" provides the frame for the 
> test
> cases.

Exactly.

>
> Here are some ideas for this DUnit frame (from the previous
> DUnit):
> - provide means to let a test case pass iff an expected 
> exception is thrown

You already have it: std.exception.assertThrown().


> - use command-line args to filter test cases to be executed

Nice, I'll implement in the DUnitMain mixin.


> - add an XML test report for inspection by machines

Not big on the priority list, but yes, some kind of automation
for Ant and IDEs would be cool. The reason I tried to stay
compatible with java style tests output is so that some existing
tools might already be able to parse it.
    For xml output, I would layout the output in some form that is
already recognized by tools, and that would take me some time.
And this DUnit is still too green (but 100% solid and usable in
what it provides).
    I first want to do a graphical test runner.
I also want to have the runner precompiled outside.
So that I can stay in the test runner window, and just click
'retest' after recompiling. I got very used to this rhythm
of work, and I think it'd be nice to have it in D. For
that to work, I have to solve a few issues.

Also, I don't want to make a graphical test runner that
only works on windows or only works on unix. And I love DWT,
so I first want a DWT that everyone can depend on.
I already made DWT compile in linux 64bit which didn't work
(though not as a library, that had some issues of its own,
instead, I have to list aaalll the DWT files used in the
dmd command line).

So my priorities are (for when I have time!!):

      -Merge to latest DWT (I diverged last year when dmd 2.0.54
       was newest) and make a pull request for DWT.

      -Add more assert* to DUnit, finalizing its API so to speak.
       Any other future DUnit change will be source compatible.
       (at least until D gets user defined attributes!).

      -Solve the 'test runner compiled outside' issues.

      -Make a graphical test runner, the nicest, slickest,
       coolest one of the *Unit bunch!!

--jm