Am Mon, 21 Oct 2013 21:47:22 +0200 schrieb "ilya-stromberg" <ilya-stromberg-2...@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@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