Helper unit testing functions in Phobos (possible std.unittests)

[Jacob Carlborg]

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