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

[spir]

On Fri, 5 Nov 2010 21:37:02 -0700
Jonathan M Davis <jmdavisProg at gmx.com> 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 had similar needs myself, not in D yet, but this should come soon. Especially, the need to easily test for failure cases, which often means errors/exceptions. (I mean properly testing implies testing for the proper behaviour in failure cases. For instance, testing patterns correctly requires, in my views, more tests for proving that they do not accept what they shouldn't.)

In a dynamic language, I ended up defining a little Test type with fields for the test func properly speaking, the expected outcome (including exception types), and output messages in both succes/failure cases. Then running a test called the func, catching exception if any, and reported result. A silent mode reported only failure cases.
An advantage compared to asserts is that one can run a whole test series and get all (failure) results in one go. (Else, one needs to wrap the whole testsuite in a mega try block, catching assertionErrors, and storing results.) (I also had a TestSuite type to hold and run a series of them; its only utility was to define a series of tests all together in code, inside a single object.)
I don't know whether this kind of design fits D the language, and its coding style. (Seems there would be a problem with having the test func as attribute, since it may return anything?)


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com