I decided to stop being like Google and finally tag version 1 of unit-threaded:

https://code.dlang.org/packages/unit-threaded

From now on I'm going to focus on compilation speed (no matter how ugly that might make the implementation), and also dropping support in v2.x.x for anything other than unittest blocks (bye bye test classes and functions).

On Thu, 2020-05-28 at 15:35 +0000, Atila Neves via Digitalmars-d-announce wrote:
> I decided to stop being like Google and finally tag version 1 of unit-threaded:
> 
> https://code.dlang.org/packages/unit-threaded
> 
>  From now on I'm going to focus on compilation speed (no matter
> how ugly that might make the implementation), and also dropping
> support in v2.x.x for anything other than unittest blocks (bye
> bye test classes and functions).

This last is sad, for me. I like using test functions rather than named unittest blocks.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:
> [snip]
>
> This last is sad, for me. I like using test functions rather than named unittest blocks.

I recall playing with them when it was originally announced and thought they were quite nice, but I haven't used them since.

The unit-threaded library certainly seems chocked full of features. Some of them overlap with the fluent-asserts library. It may make sense to split off some of that stuff as well so that people can evaluate custom assert libraries on their own merits.

Similarly, the mocking and integration stuff could probably (?) be split off into separate packages. This would imply unit-threaded could be focused on the runner subpackage.

On 28.05.20 17:35, Atila Neves wrote:
> https://code.dlang.org/packages/unit-threaded

You got a bad @trusted:

----
import unit_threaded.light: check;
void main() @safe
{
    check!((int a) @system {
        /* ... can do unsafe stuff here ... */
        return true;
    });
}
----

I searched for "trusted" and that was the first hit. I didn't look further. There's probably more.

On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:
> On Thu, 2020-05-28 at 15:35 +0000, Atila Neves via Digitalmars-d-announce wrote:
>> I decided to stop being like Google and finally tag version 1 of unit-threaded:
>> 
>> https://code.dlang.org/packages/unit-threaded
>> 
>>  From now on I'm going to focus on compilation speed (no matter
>> how ugly that might make the implementation), and also dropping
>> support in v2.x.x for anything other than unittest blocks (bye
>> bye test classes and functions).
>
> This last is sad, for me. I like using test functions rather than named unittest blocks.

Out of curiosity, what is the difference for you between:

testFoo() { /* ... */ }

and:

@("foo")
unittest { /* ... */ }

On Thursday, 28 May 2020 at 19:01:22 UTC, jmh530 wrote:
> On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:
>> [snip]
>>
>> This last is sad, for me. I like using test functions rather than named unittest blocks.
>
> I recall playing with them when it was originally announced and thought they were quite nice, but I haven't used them since.
>
> The unit-threaded library certainly seems chocked full of features. Some of them overlap with the fluent-asserts library. It may make sense to split off some of that stuff as well so that people can evaluate custom assert libraries on their own merits.
>
> Similarly, the mocking and integration stuff could probably (?) be split off into separate packages. This would imply unit-threaded could be focused on the runner subpackage.

The assertions are their own subpackage, as is the runner, and mocking, and integration.

On Friday, 29 May 2020 at 14:20:53 UTC, ag0aep6g wrote:
> On 28.05.20 17:35, Atila Neves wrote:
>> https://code.dlang.org/packages/unit-threaded
>
> You got a bad @trusted:
>
> ----
> import unit_threaded.light: check;
> void main() @safe
> {
>     check!((int a) @system {
>         /* ... can do unsafe stuff here ... */
>         return true;
>     });
> }
> ----
>
> I searched for "trusted" and that was the first hit. I didn't look further. There's probably more.

That got fixed a few weeks back - your code doesn't compile for me.

On 01.06.20 10:49, Atila Neves wrote:
> That got fixed a few weeks back - your code doesn't compile for me.

Huh. Maybe you forgot to commit that? I'm just running this through `dub --single test.d`:

----
/+ dub.json:
{
    "dependencies": {
        "unit-threaded": "~>1.0.0",
    },
}
+/
import unit_threaded.light: check;
void main() @safe
{
    check!((int a) @system {
        /* ... can do unsafe stuff here ... */
        return true;
    });
}
----

https://run.dlang.io/is/NbiYBB

On Mon, 2020-06-01 at 08:41 +0000, Atila Neves via Digitalmars-d-announce
wrote:
[…]
> Out of curiosity, what is the difference for you between:
> 
> testFoo() { /* ... */ }
> 
> and:
> 
> @("foo")
> unittest { /* ... */ }

Primarily consistency with the way all other unit test frameworks which are
based on test functions – I am not a fan of class-based unit tests hence using
pytest in favour of unittest in Python. Using functions just feels more
normal.

Secondarily lack of understanding of the scope rules of multiple unittest blocks.

In the end though I use whatever is provided. So if functions are for the chop, I will switch to using labelled unittest blocks.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Monday, 1 June 2020 at 09:08:01 UTC, Russel Winder wrote:


> Secondarily lack of understanding of the scope rules of multiple unittest blocks.
>
> In the end though I use whatever is provided. So if functions are for the chop, I will switch to using labelled unittest blocks.

Each unittest block is a function.