CURL Wrapper: Congratulations Next up: std.serialize

[Jacob Carlborg]

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