std.unittests for (final?) review

[Jonathan M Davis]

On Monday 03 January 2011 16:39:49 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.372.1294029902.4748.digitalmars-d at 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.

Well, I'm certainly up for that if enough people agree.

> 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.

Well, it's not possible to overload assert, so that sort of thing really doesn't 
work. You're kind of stuck with something JUnit-ish in terms of names, though 
assertCmp and assertOpCmp both take a string for the operator, so you don't have 
assertLessThan, assertGreaterThan, etc. And what's there uses lazy instead of 
string mixins, because it's cleaner that way. lazy does the job just fine.

And even if you could overload assert, you'd likely run into the same sort of 
problems that come up when you try and overload constructors and the like and 
the parameters aren't different enough to allow you to do all of the overloads 
that you want to do. At least JUnit-like naming is clear, and you're only going 
to use it unit tests, so it's fairly confined. So, if it bothers you, at least it 
doesn't affect your actual program code.

> 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.

Well, like I said, these functions are intended to work the same way that assert 
does. They're not intended to alter how unit testing works in D, and continuing 
a unittest block after an assertion/unit testing function fails would be 
changing how they work. It may be worthwhile to figure out a way to have some set 
of functions which report errors but don't actually throw an AssertError for 
those who really want that sort of thing, but without hooks of some kind in the 
built-in unit testing framework, I don't know how you'd do that very cleanly. 
So, if that sort of functionality is really wanted, changes are going to have to 
be made in the core unit testing stuff (which is implemented in druntime, I 
think, but it may require compiler changes as well).

- Jonathan M Davis