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
[email protected]
http://michelf.com/
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
