dunit 0.7.0 released

[ilya-stromberg]

On Monday, 21 October 2013 at 19:02:45 UTC, Gary Willoughby wrote:
> 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
>
> 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..

+1