dunit 0.7.0 released

[Gary Willoughby]

On Monday, 21 October 2013 at 11:58:14 UTC, Jonathan M Davis 
wrote:
> On Monday, October 21, 2013 13:48:16 Dicebot wrote:
>> On Monday, 21 October 2013 at 11:09:25 UTC, ilya-stromberg 
>> wrote:
>> > Guys, we have at least 5 (!) different unit test projects!
>> > Can you cooperate your efforts to create one, but wonderful?
>> 
>> ...and add it to Phobos review queue ;)
>
> I confess that I don't understand why anyone is creating any 
> unit test
> projects for D, and I'd likely vote against any attempt to add 
> such a thing to
> Phobos. D has built in unit testing functionality, and it works 
> great. Maybe
> some additional assert-like functions could be useful (similar 
> to assertThrown
> or assertNotThrown), but we really don't need much beyond what 
> the language
> provides.
>
> - Jonathan m Davis

"640K ought to be enough for anybody"

Seriously though, unit testing is a major tool that all languages 
should have access to. The built-in stuff is adequate for very 
simple testing on simple types such as asserting something is 
true, etc. But when you're writing tests for a class that need 
dependencies then the built-in stuff won't cut it. The framework 
i'm currently working allows for mocking of dependencies which in 
itself is a big deal. Replacing dependencies with 'fake' stubs is 
something which makes unit tests a lot clearer and less 
complicated. It also means i can override the return value of any 
method at runtime to pretend returned data is real there too.

I've also extended the assert mechanism in the D runtime to 
create better errors. Instead of just getting:

     core.exception.AssertError at file(57): Assertion failure

You now get:

     
+----------------------------------------------------------------------
     | Failed asserting equal
     
+----------------------------------------------------------------------
     | File: file.d
     | Line: 57
     
+----------------------------------------------------------------------
     | ✓ Expected value: (int[]) [1, 2, 3, 4, 5]
     | ✗ Actual value: (int[]) [1, 2, 4, 5]

This is way more clear exactly what and where failed. This is 
essential when unit testing using structs, arrays, classes, etc.. 
as you need this information to truly narrow down exactly what 
failed. Extending stuff like this also helps with overall project 
reporting, writing to a file or drawing pretty graphs etc..