CURL Wrapper: Congratulations Next up: std.serialize

[Jonathan M Davis]

On Saturday, December 31, 2011 11:05:58 Tobias Pankrath wrote:
> > I think that the AssertError's message (which includes the file and line
> > number of the failure) and its stack trace are plenty. It's exactly what
> > you need and nothing else.
> > 
> > - Jonathan M Davis
> 
> I want to have such a summary.

I don't see any reason to put that in the standard library. There's nothing 
wrong with 3rd party solutions which give additional functionality, but D's 
unit test framework is designed to be minimilistic, and I don't think that 
adding anything beyond what it does now in terms of summary makes any sense. 
The only major issue in that regard IMHO is the fact that no further unittest 
blocks within a module are run after one fails. Even if it did, I still don't 
think that a fancier summary would be worth having - especially in the 
standard library.

If you want that sort of summary, you probably want it printing stuff out on 
success too, and that definitely goes against how the built-in framework works 
(since it follows the typical unix approach of failure printing out stuff and 
success printing nothing). So, I think that that really makes more sense as a 
3rd party solution rather than as part of the standard library. And in 
general, 3rd party solutions are more likely to be customizable in a way you'd 
like rather than picking a single way of doing things.

> What's about running only certain unittests?

D's unit test framework isn't designed that way at this point. You need named 
unit tests for that to really make sense. It could theoretically be added and 
would be nice, but that would require changes to the language (though 
fortunately, they would be backwards compatible changes). So, we may see that 
eventually but not right now. At this point, the closest that you get to that 
is to unit test each of your modules separately rather than all at once. And 
actually, even major unit testing frameworks such as JUnit often end up 
running all of the unit tests within a module/file when you tell them to run a 
single unit test (probably in part since one unit test can theoretically affect 
the ones that follow it, and probably in part due to how they're implemented). 
So, I'm not sure how common being able to really run a single unit test is 
anyway. It would be a nice addition, and we may get it eventually, but it's 
not going to happen right now.

- Jonathan M Davis