"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message
news:mailman.372.1294029902.4748.digitalmar...@puremagic.com...
>
> std.unittests is intended to help you write more informative unit test
> code and
> save you from writing some of the boilerplate code in unit tests, but it
> is
> _not_ intended to fundamentally alter how unit tests in D function.
>
> So, please have a look at the code. I've made changes according to
> previous
> suggestions, and I think that the result is quite a bit better than my
> original
> proposal. If all goes well, perhaps Andrei will put it up for vote soon,
> and we
> can actually have it in Phobos.
>
I'm absolutely in favor of it going into Phobos, even if it goes in 100%
as-is.
That said, there are three issues I have with it (in no order):
1. I completely agree with other people's suggestions of changing some of
the function names.
2. The assertOp* functions are an ugly JUnit/NUnit-style kludge. I'd much
rather use something that's more like:
int x = 2;
assert(x == 7, x);
// Or
assert(q{_==7}, x);
// Or
assert(q{ #x#==7 });
// etc, anything that involves writing a real expression...
Output:
Failed: [x == 7] x: 2
Some of those exact thing can't be done right now, but it's been suggested
that there should be some _traits-ish way to get the actual code sent to a
function's param as a string. That would make a lot of it possible. Even
without that, it would also be possible with mixins and q{}. And yes, people
whine about that sort of thing being ugly, and I agree, but this is just
another reason to clean mixins up. And even with the mixin() and q{} noise,
I'd still vastly prefer it because of the same reason I'm a proponent of
operator overloading - I don't ever want to have to write a basic expression
in some bizarre "Add(x, y)" style.
3. Without the ability make them non-fatal (and catch & report
unexpectedly-thrown exceptions, and optionally "fatalize" after a few of
them have been run), I'd never use any of those assert* functions directly.
It's possible they might be useful in the implementation of an alternate
unittest lib, though.
