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