Helper unit testing functions in Phobos (possible std.unittests)

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.125.1289018234.21107.digitalmars-d at puremagic.com...
> I'm proposing a possible new module for phobos which would be called
> std.unittests. The code and DDoc file can be found here: 
> http://is.gd/gLH9Q
>
> Or you can look at the code here directly (though it has poor 
> highlighting):
> http://ideone.com/EOlod
>
> The module contains a set of helper functions for unit tests which are an
> improvement over simply using assert. I have them to be very helpful in 
> the unit
> tests in my proposal for std.datetime. My unit tests are more concise, 
> easier to
> read, and much easier to debug because of them. assertEqual() and
> assertExcThrown() have been particularly useful.
>
> assert is a great tool, but simply telling you that an assertion failed is 
> not
> as useful as telling you _how_ it failed, and a function like 
> assertExcThrown()
> (which, as you may guess, asserts that a particular exception was thrown 
> by a
> particular function call) really reduces the boiler plate code that you 
> have to
> write for testing what it tests. So, I find such helper functions are 
> extremely
> useful.
>
> Because I have used them so extensively in std.datetime, they are pretty 
> much
> either going to have to be added as a module to Phobos or added as private
> helper functions in std.datetime. Personally,  I think that they (or 
> something
> very similar to them) merit being added as a new module in Phobos, which 
> can be
> expanded upon as others come up with particularly useful unit testing 
> functions.
>
> So, I'm requesting that the folks here on the list have a look at my 
> module and
> review it for possible inclusion in Phobos. I don't know what Andrei's 
> position
> on them is (he rightly focused his review of my datetime code on the 
> date/time
> functionality and API rather than its unit tests and didn't mention my 
> unit
> testing functions at all), but I think that such a module would be of 
> great
> worth and would like other's opinions on it.
>

I made a very similar thing in my SemiTwist D Tools library, so I can 
definitely attest to D's need for all of this.

My comments on this one, based on a breif skim of the doc:

I would try to change it so this:

assertOpCmp!("<")(myfunc(), 7, "My test failed!");

Can be written more like these:

assert!("_ < 7", "myfunc()", "My test failed!")();
assert!("_1 < _2", "myfunc()", "7", "My test failed!")();
assert!("_1 < _2", "myfunc()", "somethingElse()", "My test failed!")();

Aside from being more flexible, this way when it fails it can report much 
more relevent information that can actually compete with JUnit/NUnit. For 
instance, even with the custom message omitted, it could still give info 
like:

Failed: 'myfunc() < 7'
'myfunc()' was '13'

It may require it be used like 'mixin(assert!(blah blah))', but that's a big 
part of why I've been saying for a loooong time that it needs to be possible 
to make CTFE's intended for string mixins to be mixed in *without* the 
"mixin(...)" mess. Because as it is, if you present an interface that 
requires it be wrapped in "mixin(...)", people will bitch about the extra 
noise and refuse to use it, rendering string mixins minimally useful. (Last 
time I suggested this we got the ability to make *template* mixins that are 
usable without "mixin", which is caparitively useless.)

Also, I'd say if file/line info can't be inferred automatically because of 
varargs, then the interface needs to lose the vararg ability. It'd be nice 
to have, but not needing to provide line/file info manually is much nicer. 
Although, we could probably have both by using the suggestion above (ie, 
make the whole thing generate a string to be mixed-in).

Do the 'assertEqual', 'assertOpCmp', etc, all report if an exception was 
thrown (and if so, what exception)? If not, they should.