std.unittests [updated] for review

Jonathan M Davis jmdavisProg at gmx.com
Sun Jan 30 05:39:24 PST 2011


On Sunday 30 January 2011 05:28:36 SHOO wrote:
> (2011/01/24 23:34), Jonathan M Davis wrote:
> > In case you didn't know, I have a set of unit test helper functions which
> > have been being reviewed for possible inclusion in phobos. Here's an
> > update.
> > 
> > Most recent code: http://is.gd/F1OHat
> > 
> > Okay. I took the previous suggestions into consideration and adjusted the
> > code a bit more. However, most of the changes are to the documentation
> > (though there are some changes to the code). Some of the code
> > duplication was removed, and the way that some of the assertPred
> > functions' errors are formatted has been altered so that values line up
> > vertically, making them easier to compare. The big change is the docs
> > though. There's now a fake version of assertPred at the top with an
> > overall description for assertPred followed by the individual versions
> > with as little documentation as seemed appropriate while still getting
> > all of the necessary information across. A couple of the functions still
> > have irritatingly long example sections, but anything less wouldn't get
> > the functionality across.
> > 
> > In any case. Here's the updated code. Review away. Andrei set the vote
> > deadline for February 7th, at which point, if it passes majority vote,
> > then it will go into Phobos. The number of functions is small enough now
> > (thanks to having consolidated most of them into the fantastically
> > versatile assertPred) that it looks like it will likely go in
> > std.exception if the vote passes rather than becoming a new module. So,
> > the std.unittests title has now become a bit of a misnomer, but that's
> > what I've been calling it, so it seemed appropriate to continue to label
> > it that way in the thread's title.
> > 
> > - Jonathan M Davis
> 
> To be frank, I don't think that such a helper is necessary.
> I think these helpers will harm intuitive readability of unittest code.
> For unittest code, it is necessary to be able to understand easily even
> if without the document.

Do you really find

assertPred!"=="(min(5, 7), 5);

to be all that harder to understand than

assert(min(5, 7) == 5);

I find that assertPred results in code which is quite easy to read. And the 
functions assertThrown and assertNotThrown are error-prone to reimplement, and 
definitely cut down on boiler plate code if you use them to test that functions 
properly throw or don't throw exceptions.

I fail to see how these functions would make unit testing code harder to read. 
Every unit testing framework that I've ever used (aside from what's built in to 
D) has had helper functions to do what it does. And they result in much better 
error messages than assert gives you.

I don't see how these functions could be anything but an improvement. But even 
if they get into Phobos, you obviously don't have to use them. Worst case, you 
have to edit code where someone else used them. Regardless, I really don't think 
that they hard code understandability at all.

- Jonathan M Davis


More information about the Digitalmars-d mailing list