std.unittests for (final?) review
Jonathan M Davis
jmdavisProg at gmx.com
Sun Jan 2 20:44:50 PST 2011
Okay. As some of you are aware, I created a module with unit testing functions
when I wrote std.datetime, and it really helped with writing the unit tests for
std.datetime. It has been at least somewhat reviewed here previously, and that
has definitely improved it. However, it has not yet been decided whether it's
going to go into Phobos along with std.datetime. I'd like it to, but it hasn't
been voted on, and I'm not sure that it's been reviewed as heavily as it should
be. So, I'm posting the most up-to-date version in the hopes of getting any
necessary changes found and made so that it can be voted on. Andrei has yet to
weigh in on std.unittests at all, so I don't know if we're actually going to get
a vote on it, but I'm presenting it for (final?) review so that it can be voted
in if that's what he wants to do.
The code: http://is.gd/jZEVl
Both the source file and the ddoc hmtl file are included. And unlike std.datetime,
it's actually straightforward enough that it makes sense for your average
program to actually look at it.
To be clear, this module has 2 purposes:
1. Improve error messages on test failure. A good example of this is
assertEqual, which prints out both of the values being compared so that you
don't have to add a print statement (or run a debugger) and rerun the test to
see what the actual values were.
2. Reduce boiler-plate code in unit tests. A good example of this is
assertExThrown. Testing whether a function call actually throws an exception
like it's supposed to becomes a single line of code instead of being around 10
lines.
This module does _not_ attempt to change how unit testing in D fundamentally
works. It does not print out on success. It doesn't make it so that a unittest
block continues after a failure occurs in that block. All of the assertXXX
functions throw an AssertError upon failure - just like assert does, but the
message in the AssertError is far more informative. While improvements can be
made to how unit tests work in D, I believe that that should be addressed by
actually making those improvements to the core language as opposed to using a
module in Phobos to change things. You shouldn't _need_ std.unittests to write
unit testing code.
std.unittests is intended to help you write more informative unit test code and
save you from writing some of the boilerplate code in unit tests, but it is
_not_ intended to fundamentally alter how unit tests in D function.
So, please have a look at the code. I've made changes according to previous
suggestions, and I think that the result is quite a bit better than my original
proposal. If all goes well, perhaps Andrei will put it up for vote soon, and we
can actually have it in Phobos.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list