dunit 0.7.0 released

[Marco Leise]

Am Mon, 21 Oct 2013 21:47:22 +0200
schrieb "ilya-stromberg" <ilya-stromberg-2009 at yandex.ru>:

> 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

We had a discussion about verbose contract assertion failures
a while ago. I did something similar, with an API like that:

ensure!"=="(x, [1, 2, 3, 4, 5], "x isn't the ordered list of integers from 1 to 5");

It has its shortcomings though, especially when you need x to
be one of a set of values or a power of 2 etc...

Btw: Is ✓ and ✗ supported on Windows Vista and XP ?

-- 
Marco