[phobos] Silent failure of std.container unittests

[Michel Fortin]

Le 2010-07-17 à 10:10, Jonathan M Davis a écrit :

> On Saturday 17 July 2010 05:17:09 Michel Fortin wrote:
>> As other mentioned, what I do here with nested unit tests could easily be
>> implemented by offering the user a new library function too. I just happen
>> to think what I'm proposing here is more elegant.
> 
> I'd have to argue with you on that one. Personally, I find it to be far uglier 
> than simply replacing assert with expect in cases where you don't want the test 
> to stop on failure. A unittest block without braces is a bit odd, but I could 
> see that working and not being a big deal. But a unit test block inside another? 
> Sure, you could do it, but I think that it would be confusing to new users. It's 
> also more verbose than simply changing assert to expect, and I think that it's a 
> lot uglier. Obviously, this is at least somewhat subjective, however, since you 
> clearly think that nesting unittest is more elegant.

Well, I did believe it was more elegant a few hours ago while looking into it. Now I'm more ambivalent: both are fine with me if the library function has a good name which does not clash easily while being short enough. I do think 'check' or 'verify' are too clash-prone. Perhaps 'expect' would be a better choice.


> Not to mention, I am a proponent of the idea of named unit tests (e.g. 
> unittest(test_name) {}). And they don't really make sense when nested. Sure, you 
> could have named external ones and non-named nested ones, but then you'd have to 
> worry about whether a test was nested or not when allowing a name on it.

Assuming we add one day the capability to give a name to a module-level unittest, why couldn't we do the same for a nested unittest?

Note that the implementation I'm proposing (the __doUnitTest function) would make it very easy to add extra features to unittest because the compiler could simply insert a call to __doUnitTest with more arguments (such as a name) and the runtime would do what it wants with it. This works both with nested and non-nested unit tests.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/