On Thursday, 26 September 2013 at 06:07:50 UTC, Jacob Carlborg wrote:
> On 2013-09-25 21:55, Dicebot wrote:
>
>> UDAs + recent trait to get all unit-tests during compile-time really
>> favors instead having lot of small independent annotated unit-test blocks.
>
> If you have more than one test per unit test block you always need to run them together, and in the declared order. Example:
>
> unittest
> {
>     @test("foo")
>     {
>         assert(1 == 1);
>     }
>
>     @test("bar")
>     {
>         assert(1 == 2);
>     }
> }
>
> You cannot run "foo" separated from "bar". They all will always run together. You also cannot run "bar" before running "foo". Running tests like this makes it very easy to introduce order dependencies between the tests.

I was saying that if you want to have some tests independent, it makes much more sense to do it this way:

```
@test("foo") unittest
{
    assert(1 == 1);
}

@test("bar") unittest
{
    assert(1 == 2);
}
```

..and let tests within one block terminate on first failure. That should integrate better with existing tooling when no external testing library/framework is connected.

On 2013-09-26 13:12, Dicebot wrote:

> I was saying that if you want to have some tests independent, it makes
> much more sense to do it this way:
>
> ```
> @test("foo") unittest
> {
>      assert(1 == 1);
> }
>
> @test("bar") unittest
> {
>      assert(1 == 2);
> }
> ```
>
> ..and let tests within one block terminate on first failure. That should
> integrate better with existing tooling when no external testing
> library/framework is connected.

Exactly. I guess I misunderstood you. Although I would consider "having lot of small independent annotated unit-test blocks" be basically what you're showing above.

-- 
/Jacob Carlborg

On Thursday, 26 September 2013 at 14:51:16 UTC, Jacob Carlborg wrote:
> Exactly. I guess I misunderstood you. Although I would consider "having lot of small independent annotated unit-test blocks" be basically what you're showing above.

Beg my pardon, bad wording from my side. I was referring to approach when testing framework defines some sort of own testing DSL and uses it for test case decoupling within one unit-test block - as far as I understand it is what some of currently existing D testing frameworks do.

Key point here is that good testing library should augment built-in facility, not replace it. Fallback to built-ins can still be useful.

On Wednesday, 25 September 2013 at 21:00:00 UTC, Jacob Carlborg wrote:
> There are property functions at line 374 and below to set the assert handler.

Only the deprecated version works as expected.

import core.exception;
import std.stdio;

alias void function(string file, size_t line, string msg) AssertHandler;

AssertHandler handler = function(string file, size_t line, string msg)
{
	writefln("File: %s", file);
	writefln("Line: %s", line);
	writefln("Message: %s", msg);
};

void main(string[] args)
{
	// assertHandler = handler; // <--- Private!
	setAssertHandler(handler); // <--- Works but deprecated

	assert(false, "Test message.");
}

On 2013-09-26 16:56, Dicebot wrote:

> Beg my pardon, bad wording from my side. I was referring to approach
> when testing framework defines some sort of own testing DSL and uses it
> for test case decoupling within one unit-test block - as far as I
> understand it is what some of currently existing D testing frameworks do.

Ok, I see. Yes, there are some libraries that does that.

> Key point here is that good testing library should augment built-in
> facility, not replace it. Fallback to built-ins can still be useful.


-- 
/Jacob Carlborg

On 2013-09-26 20:18, Gary Willoughby wrote:

> Only the deprecated version works as expected.
>
> import core.exception;
> import std.stdio;
>
> alias void function(string file, size_t line, string msg) AssertHandler;
>
> AssertHandler handler = function(string file, size_t line, string msg)
> {
>      writefln("File: %s", file);
>      writefln("Line: %s", line);
>      writefln("Message: %s", msg);
> };
>
> void main(string[] args)
> {
>      // assertHandler = handler; // <--- Private!
>      setAssertHandler(handler); // <--- Works but deprecated
>
>      assert(false, "Test message.");
> }

I don't know which version of DMD you're using or when this part of druntime was update, but it's clearly not private according to the source code:

https://github.com/D-Programming-Language/druntime/blob/master/src/core/exception.d#L380

-- 
/Jacob Carlborg

On Thursday, 26 September 2013 at 19:25:46 UTC, Jacob Carlborg wrote:
> I don't know which version of DMD you're using or when this part of druntime was update, but it's clearly not private according to the source code:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/exception.d#L380

I knowm, it's weird, i've been trying to find out why it's private, everything looks like it's public. Try running the code i posted see if you can get it to work.

On Sunday, 22 September 2013 at 13:13:29 UTC, linkrope wrote:
> Have a look at https://github.com/linkrope/dunit, especially at
> the "Related Projects".

Thanks for the link to https://github.com/atilaneves/unit-threaded!

My library, unit-threaded, does just that. All unittest blocks from a module show up as one test case in the output.

On Thursday, 26 September 2013 at 14:56:49 UTC, Dicebot wrote:
> On Thursday, 26 September 2013 at 14:51:16 UTC, Jacob Carlborg wrote:
>> Exactly. I guess I misunderstood you. Although I would consider "having lot of small independent annotated unit-test blocks" be basically what you're showing above.
>
> Beg my pardon, bad wording from my side. I was referring to approach when testing framework defines some sort of own testing DSL and uses it for test case decoupling within one unit-test block - as far as I understand it is what some of currently existing D testing frameworks do.
>
> Key point here is that good testing library should augment built-in facility, not replace it. Fallback to built-ins can still be useful.

On 2013-09-26 22:39, Gary Willoughby wrote:

> I knowm, it's weird, i've been trying to find out why it's private,
> everything looks like it's public. Try running the code i posted see if
> you can get it to work.

It works fine using DMD 2.063.2 on Mac OS X.

-- 
/Jacob Carlborg