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@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..
