Unit tests in D

[bearophile]

Lutger:

>Anyway I think if unittests can get a name as a parameter and dmd let's the user set the AssertError handler, that will be a sufficient hook to provide some useful user extension of the unittest system.<

Ah, I didn't think about an AssertError handler. Among other things, it solves my point B.
Digging a little, I have seen core.exceptions has already a setAssertHandler, but it's not useful yet:
http://d.puremagic.com/issues/show_bug.cgi?id=3208


> One tiny tip: test.d(6): unittest sqr failed
> This way ide's and editors can parse it like regular D errors and jump to the failed test.

Good.


>I think there's a report in bugzilla from Andrei requesting that the unittests themselves can be turned into documentation.<

Given the size of my unittests I don't think this is good idea in general.

Maybe Andrei was trying to add something like python doctests to D. I think to do this well it can be necessary a way to tell apart "documentation doctests" from normal (and often boring or large) unittests.


>Shouldn't this be part of a tool that compiles and runs tests of each module?<

Most of the features I have listed are meant for an IDE, while this one is for programmer that uses just the command line with no tools :-)
And to enable/disable test groups things gets a little more complex.


>rdmd has the option --main, together with -unittest you can easily do this.<

This page doesn't list that option:
http://www.digitalmars.com/d/2.0/rdmd.html

rdmd prints:
--eval=code       evaluate code +á la perl -e (multiple --eval allowed)
--loop            assume "foreach (line; stdin.byLine()) { ... }" for eval
--main            add a stub main program to the mix (e.g. for unittesting)

I don't understand how to use those three switches. Do you know where I can find usage examples for those three?

  
>This unittest halts with an AssertError inside inner().<

That's why my throws!()() has to return a boolean instead of just asserting :-(
I don't know if this can be seen as a dmd bug.


>I think I like the idea that unittests should be close to the code it tests, otherwise it is a different kind of test.<

There are strong opionions on this. Some people love this, other people ate it. Some people can appreciate to move large amounts of unittests in separate modules. The best thing is to leave the programmers to put the unittests where they want.


>Perhaps we should consider ddoc, contracts and unittest as much part of the code as the code itself?<

Of course :-)

Bye and thank you for your answers and ideas,
bearophile