std.unittests for (final?) review

[Jonathan M Davis]

On Wednesday, January 05, 2011 18:54:32 Ary Borenszweig wrote:
> I prefer assert, assertFalse, assertEqual and assertNotEqual.
> 
> Compare this:
> assertPredicate!"a < b"(1 + 1, 3);
> 
> To this:
> assert(1 + 1 < 3)
> 
> Or to this:
> 
> assertLess(1 + 1, 3)
> 
> Ok, the first one is more generic. But so the error message for the
> assertion failure will be more generic, when you want exactly the opposite
> to happen. Plus your brain has to think more to read it (starting from the
> point that it's longer).
> 
> assertPredicate!"<"(1 + 1, 3) reminds me of polish notation, which is very
> good for machines but not very good for humans.
> 
> Sorry, you can have more specific error messages: on compile time you parse
> the given string and see. If it's "<" then you give an error message
> regarding less. Then you end up having a huge function, bearly
> understandable, and with a huge documentation. On the other case you end
> up having very well defined functions, very simple to read and write, well
> documented, and also with a very simple implementation. What's the benefit
> of inlining all of that if it's going to be used in unit tests or in debug
> mode?
> 
> I'm not a big fan of IDEs anymore but having many functions also helps with
> the autocompletion, to get the code right on the first shot, instead of
> assertPredicate!insertYourStringHere(...).

Valid points. However, assertPred!"=="(1 + 1, 3) isn't much harder to read than 
assertEqual(1  + 1, 3). Also, you could create an alias for assertPred"==" to 
assertEqual, if you wanted to. So, we could easily add assertEqual and the like 
as aliases if enough people really wanted them.

Also, assertPred can definitely be made to print out error messages just as 
informative as what I have now. You just either have specialized versions of 
assertPred or you have lots of static ifs inside of asertPred (or both).

And actually, now that I think of it, it should be possible to have specific 
tests for each overloaded operator function (rather than the operator itself) in 
the same manner. So, assertOpOpAssign could become assertPred!"opOpAssign", and 
assertPred would be smart enough to handle it correctly.

Assuming that I can pull if off correctly (which I should be able to given a bit 
of time and effort), assertPred could be quite clean and very powerful. And if 
the name bothers you enough, alias can fix it for you.

- Jonathan M Davis