Simple bolt-on unittest improvement

[Christopher Wright]

Justin Johansson wrote:
> Hope it doesn't sound like I just discovered America but being a D newbie one is keen to play with all the language features.  So soon getting round to playing with D's unit test facility with JUnit (Java test unit) experience in mind,  found that I wanted all my tests to run even if one or the tests would otherwise fail on some assert.  Googled for DUnit as a hunch such beast might exist and sure enough found DUnit for D somewhere after the Delphi hits.
> 
> http://www.dsource.org/projects/dmocks/wiki/DUnit
> 
> Sure enough DUnit writeup spoke about need for continuous testing in D as had occurred to me.  Then it dawned upon me that there really wasn't any need to go away from D's built-in unit test facility to achieve this and hence no need really for the DUnit approach.
> 
> The idea is to keep working within D's built in unit test facility; just don't use assert statements in current fashion as if one fails then whole test stops running.  Simply replace assert statements with a function call that tests and records the assert condition instead .. much like in JUnit where you have functions like assertTrue, assertEquals etc.  Then just inside your main program you call up your unit test pretty print report and decide then (say based upon number of failed tests relative to total number of tests) whether to continue with your mainline code or bail out.
> 
> The regime now looks something like this:
> 
> Class1:
> 	unittest {
> 		jjunit.expectEquals( __FILE__, __LINE__, some_x, some_y);
> 		jjunit.expectTrue( __FILE__, __LINE__, somecond);
> 	}

And you don't want to use dunit's assertions because they throw 
exceptions, which means you don't see more than one error when running 
the application.

The problem with this is that you are going to continue running a test 
after an assertion fails. This is fine for a lot of unittests -- in fact 
beneficial -- but in others it's going to be guaranteed failure:

auto foo = buildFoo();
expect(foo !is null);
expect(foo.bar == 17);

If you really want to work with d's builtin unittests, your strategy is 
required. Personally, I dislike it. That's why dunit is as it is.