On Thursday, 8 May 2014 at 18:54:30 UTC, Jacob Carlborg wrote:
> I mean, what the h*ll does this unit test tests:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/numeric.d#L995

It is explained in comments there. And it won't become more simple if you add some fancy syntax there. It looks complicated because it _is_ complicated, not because syntax is bad.

> @describe("foo")

This is redundant as D unittest blocks are associated with symbols they are placed next to.

> {
>     @it("should do something useful") unittest {

This is essentially @name with an overly smart name and weird attribute placement.

> Is not so much different from what you suggested with named unit tests.

It introduces bunch of artificial annotations for something that can be taken care of by a single attribute as a side effect. Not KISS.

On 2014-05-09 13:57, Dicebot wrote:

> This is redundant as D unittest blocks are associated with symbols they
> are placed next to.

I prefer to keep my tests in a separate directory.

> It introduces bunch of artificial annotations for something that can be
> taken care of by a single attribute as a side effect. Not KISS.

I just don't agree.

It's a bit hard to do in D, but in the Ruby version, for each "describe" block an anonymous class is created. Nested blocks inherits from the outer blocks. The "it" blocks are evaluated inside an instance of the closest "describe" block. This makes it very nice to setup data for the tests. You can have helper methods in the "describe" blocks, overriding methods in the outer blocks and so on, very convenient.

As a bonus, you can run the test with a special formatter. This will print all strings passed to the "describe" and "it" blocks in a structured way. Suddenly you can generate documentation of how you're system is supposed to work.

-- 
/Jacob Carlborg