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

Jonathan M Davis jmdavisProg at gmx.com
Sat Nov 6 01:21:25 PDT 2010


On Saturday 06 November 2010 00:56:06 spir wrote:
> 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?)

I believe strongly that a unit test block which has a failure should end 
excecution. For many such tests, continuing would be utterly pointless, since 
each successive test relies on the last. Unfortunately, D currenly stops the 
unit tests running for an entire module if one fails. This problem has been 
discussed before, and it seems likely that it will change so that each unittest 
block will be run even if the previous ones in the module failed, but that 
change has not yet been made. Regardless, I do _not_ think that it is correct 
behavior to continue running the tests in a unittest block there is a failure in 
that block.

- Jonathan M Davis


More information about the Digitalmars-d mailing list