On 2011-12-31 11:37, Jonathan M Davis wrote:
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
It would be possible to implement named unit tests only in library code.
It would not have as nice syntax as if it was implemented in the
language but still possible.
In Ruby on Rails I run single unit tests all the time. Why would I run
all the unit tests, which can take five minutes, when I just can run one
unit test and it takes just one second?
When your doing test/behavior driven development (T/BDD) it's certainly
nice to be able to run single unit tests, because you run it all the time.
--
/Jacob Carlborg
