std.unittests for (final?) review

[Jonathan M Davis]

On Monday 03 January 2011 01:50:48 bearophile wrote:
> Jonathan M Davis:
> > While improvements can be
> > made to how unit tests work in D, I believe that that should be addressed
> > by actually making those improvements to the core language as opposed to
> > using a module in Phobos to change things. You shouldn't _need_
> > std.unittests to write unit testing code.
> 
> I think it's wrong to design a built-in unit test system able to do most of
> the things a real unit test system is expected to work, because it's a lot
> of stuff and because 10-15 years from now the best design for an unit test
> system may be different, and there are different ways to create tests. So
> I prefer the built-in unit test features to allow the creation of a good
> standard library unit test system based on the built-in one, working as an
> extension. In little programs you are free to use the built-in one.
> 
> What basic unit testing features do you think are better to become
> built-in? (Unit test names?)

The main items that I can think of are unit test names and what happens when a 
unittest block fails. We can't currently name unit tests, and while it's planned 
that every unittest block will run even if others in the module fail, at 
present, if one unittest block in a module runs, none of the other unittest 
blocks in the module run.

Other changes that some people have expressed interest in are things like having 
it printed when a test passes, and those should not be in the language or 
druntime itself. That's going to either have to be in helper functions that are 
run inside of unittest blocks or it's going to need to be possible to run 
unittest blocks externally somehow (like would be necessary if you wanted to run 
them in an IDE) and then whatever program runs them can choose to print test 
successes. But printing test successes goes against how D's unit testing 
framework is designed and IMHO would be very bad - particularly when the tests 
run before main rather than in a separate program.

What I was essentially trying to say was that I'm not trying to fundamentally 
change how unit testing in D functions, and I don't think that it really should 
be changed. Some improvements can be made, but I don't think that that's the job 
of Phobos. Such changes either need to be made in the language/druntime, or they 
need to be made in a some sort of external tool which runs D's unit tests 
differently. All that std.unittests is trying to do is to expand on what D's unit 
tests already do, not fundamentally alter how they work.

- Jonathan M Davis