std.unittests vote tally

[Jonathan M Davis]

On Tuesday 08 February 2011 07:27:55 Andrei Alexandrescu wrote:
> Vote has closed last night at 23:59:59:99, but I accepted Lars' late vote.
> 
> Thanks Jonathan for responding to comments and suggestions, and for a
> very dedicated attitude throughout.
> 
> YES votes mean wholesale acceptance of the library. NO means either
> partial acceptance or no acceptance at all.
> 
> We have eight NOs and even YESs. (In fairness I have changed my vote
> after Don committed to improve assert(), but forgot to submit it.)
> 
> NO:
> 
> SHOO (arguments: unittest code should be easy to read without prior
> knowledge)
> Don (arguments: assertPred is harder to read than assert, "don't use if
> you don't like" doesn't apply to Phobos, Phobos becomes difficult to
> read if we continue adopting clever functions, something that has any
> appearance of being complicated needs VERY strong justification. Voted
> yes for assertThrown and assertNotThrown. Asked for bugzilla enhancement
> requests to have assert obviate assertPred)
> Michel Fortin
> Brad Roberts
> David Nadlinger (yes for assertThrown, 50/50 for assertNotThrown and
> collectExceptionMsg, no for assertPred)
> spir (yes to assertThrown, abstain for assertNotThrown and
> collectExceptionMsg)
> Jim (reiterates that at best assert should be improved)
> Lars T. Kyllingstad (on the fence with assertPred)
> 
> YES:
> 
> Jens Mueller
> bearophile
> Andrej Mitrovic
> Nick Sabalausky
> Andrei Alexandrescu (contingent on reducing the size of examples)
> Masahiro Nakagawa (with a few notes)
> Andrew Wiley
> 
> Reviewer Manager's decision:
> ============================
> 
> We have had an unexpected development: we can change assert() to obviate
> assertPred(), and Don all but promised he'll look into it. This means if
> we accept the library as it is, we'll look at a function on the brink of
> deprecation for the sake of a short-term benefit. Perhaps this is not
> the best course of action.
> 
> So let's not put assertPred() for now in Phobos, though Jonathan is to
> be commended for his work which is leading to a vast improvement to a
> core facility.
> 
> assertThrown seems to be liked by a vast majority - please add to
> std.exception at your earliest convenience.
> 
> assertNotThrown and collectExceptionMsg are on the fence and it's
> unclear whether some "NO" voters want them as isolated functions. Let us
> take a one-week vote for each. I will create one thread for each.
> 
> 
> Thanks to everyone for participating, and special thanks to Jonathan!

Enhancement request for assert: 
http://d.puremagic.com/issues/show_bug.cgi?id=5547

Okay. I'll look at doing another proposal which has the functionality of 
assertPred which doesn't make sense to add to assert, though I'll probably wait 
until the voting for assertNotThrown and collectExceptionMsg is done.

I would point out, however, that it would be rather silly to include 
assertThrown and not assertNotThrown. Good unit tests should test _both_ that a 
function succeeds as it's supposed to _and_ that it fails as it's supposed to. 
So, I would hope that people vote in favor of assertNotThrown.

collectExceptionMsg isn't as critical, but it really does make it easy to test 
that exception messages are correct, since if you use collectException, you have 
to worry about checking for null before you can check the message. With 
collectExceptionMsg, it can be a an easy one-liner to check exception messages. 
Without it, you end up taking several lines, because you have to save and check 
the exception for null before you can check its message.

I'll wait for the vote on assertNotThrown and collectExceptionMsg to be 
completed before putting assertThrown in Phobos. Then it can just all be taken 
care of at once.

- Jonathan M Davis