On 2010-11-06 05:37, Jonathan M Davis wrote:
I'm proposing a possible new module for phobos which would be called
std.unittests. The code and DDoc file can be found here: http://is.gd/gLH9Q
Or you can look at the code here directly (though it has poor highlighting):
http://ideone.com/EOlod
The module contains a set of helper functions for unit tests which are an
improvement over simply using assert. I have them to be very helpful in the unit
tests in my proposal for std.datetime. My unit tests are more concise, easier to
read, and much easier to debug because of them. assertEqual() and
assertExcThrown() have been particularly useful.
assert is a great tool, but simply telling you that an assertion failed is not
as useful as telling you _how_ it failed, and a function like assertExcThrown()
(which, as you may guess, asserts that a particular exception was thrown by a
particular function call) really reduces the boiler plate code that you have to
write for testing what it tests. So, I find such helper functions are extremely
useful.
Because I have used them so extensively in std.datetime, they are pretty much
either going to have to be added as a module to Phobos or added as private
helper functions in std.datetime. Personally, I think that they (or something
very similar to them) merit being added as a new module in Phobos, which can be
expanded upon as others come up with particularly useful unit testing functions.
So, I'm requesting that the folks here on the list have a look at my module and
review it for possible inclusion in Phobos. I don't know what Andrei's position
on them is (he rightly focused his review of my datetime code on the date/time
functionality and API rather than its unit tests and didn't mention my unit
testing functions at all), but I think that such a module would be of great
worth and would like other's opinions on it.
- Jonathan M Davis
I think that the problems that this module tries to fix should instead
properly be fixed in the compiler. An assert error should be able to
show what expression failed and one failing unit test in a module should
now stop the renaming unit tests. The failing unit test would of course
stop running but not the renaming ones.
An idea is to have a function that takes a delegate and wrap the whole
test in the delegate, like this:
unittest
{
test("possibly a message here as well", {
assert(/*some condition*/);
});
}
"test" would catch all AssertErrors, collect them and then at the end
print out the result of all the tests. If one assert throws in a
delegate the whole test (delegate) will stop running but the renaming
tests in the unit test will continue to run. Since the assert error will
contain the file and line number one could also read in the file and
print out the failing line and possibly a couple of surrounding lines.
Of course it would want the compiler to do this automatically instead of
inventing a library solution.
--
/Jacob Carlborg
