New release of unit-threaded, the advanced test framework for D:

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

Besides bug fixes, the main difference is now cartesian product of types works as it did for values when it comes to parameterized tests:

------------------
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
    static assert(T0.sizeof == 1);
    static assert(T1.sizeof == 4);
}
------------------

This now generates 6 tests, one for each combination of types, similarly to what already worked with the @Values UDA.

On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves wrote:
> [snip]
>
> ------------------
> @Types!(ubyte, byte)
> @Types!(int, uint, float)
> @UnitTest
> void fun(T0, T1)() {
>     static assert(T0.sizeof == 1);
>     static assert(T1.sizeof == 4);
> }
> ------------------
>
> This now generates 6 tests, one for each combination of types, similarly to what already worked with the @Values UDA.

I'm a little confused on this. What if you have void fun(T0, T1, T2)) {}, but only two @Types listed? Does it just do the first two?

Also, there is an example in the readme on @Values of
@Values(1, 2, 3) unittest { assert(getValue!int % 2 == 0); }
What if it's not so easy to create the values? I suppose you could pass the parameters in @Values to some other function that will then create what you actually need and then test using that. Maybe good to provide some more examples of advanced usage?

On Wednesday, 30 January 2019 at 14:55:37 UTC, jmh530 wrote:
> Also, there is an example in the readme on @Values of
> @Values(1, 2, 3) unittest { assert(getValue!int % 2 == 0); }
> What if it's not so easy to create the values? I suppose you could pass the parameters in @Values to some other function that will then create what you actually need and then test using that. Maybe good to provide some more examples of advanced usage?

I suppose that if the values you want to test with require some complicated initialization only possible at runtime, @Values could be made to hold a list functions that would be called at runtime to create the values, before executing your test function.

On Wednesday, 30 January 2019 at 14:55:37 UTC, jmh530 wrote:
> On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves wrote:
>> [snip]
>>
>> ------------------
>> @Types!(ubyte, byte)
>> @Types!(int, uint, float)
>> @UnitTest
>> void fun(T0, T1)() {
>>     static assert(T0.sizeof == 1);
>>     static assert(T1.sizeof == 4);
>> }
>> ------------------
>>
>> This now generates 6 tests, one for each combination of types, similarly to what already worked with the @Values UDA.
>
> I'm a little confused on this. What if you have void fun(T0, T1, T2)) {}, but only two @Types listed? Does it just do the first two?

It would fail to compile.

> Also, there is an example in the readme on @Values of
> @Values(1, 2, 3) unittest { assert(getValue!int % 2 == 0); }
> What if it's not so easy to create the values? I suppose you could pass the parameters in @Values to some other function that will then create what you actually need and then test using that.

I've never had a need to use complicated values, so I haven't coded that.

If presented with an example, I think there's a high chance I'd consider it an anti-pattern.

> Maybe good to provide some more examples of advanced usage?

Documentation is hard. :(

I tried by using examples, but without knowing what's not clear it's hard for me to know what to do about it.

On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves wrote:
> New release of unit-threaded, the advanced test framework for D:
>
> https://code.dlang.org/packages/unit-threaded
>
> Besides bug fixes, the main difference is now cartesian product of types works as it did for values when it comes to parameterized tests:
>
> ------------------
> @Types!(ubyte, byte)
> @Types!(int, uint, float)
> @UnitTest
> void fun(T0, T1)() {
>     static assert(T0.sizeof == 1);
>     static assert(T1.sizeof == 4);
> }
> ------------------
>
> This now generates 6 tests, one for each combination of types, similarly to what already worked with the @Values UDA.

Thanks for this library. One of the more useful on code.dlang.org!

On Thursday, 31 January 2019 at 15:03:26 UTC, Colin wrote:
> On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves wrote:
>> New release of unit-threaded, the advanced test framework for D:
>>
>> https://code.dlang.org/packages/unit-threaded
>>
>> Besides bug fixes, the main difference is now cartesian product of types works as it did for values when it comes to parameterized tests:
>>
>> ------------------
>> @Types!(ubyte, byte)
>> @Types!(int, uint, float)
>> @UnitTest
>> void fun(T0, T1)() {
>>     static assert(T0.sizeof == 1);
>>     static assert(T1.sizeof == 4);
>> }
>> ------------------
>>
>> This now generates 6 tests, one for each combination of types, similarly to what already worked with the @Values UDA.
>
> Thanks for this library. One of the more useful on code.dlang.org!

Thanks!

On Thursday, 31 January 2019 at 14:42:43 UTC, Atila Neves wrote:
> [snip]
>
> I've never had a need to use complicated values, so I haven't coded that.
>
> If presented with an example, I think there's a high chance I'd consider it an anti-pattern.

I was thinking about something like what is in one of mir's sum unittests
https://github.com/libmir/mir-algorithm/blob/deb64093afa7f934956c1568358444a803d2240c/source/mir/math/sum.d#L1587
The code builds up a bunch a tuple of tuples with each containing an array and a value that the array is supposed to sum to. It then runs through them all with a foreach loop.

Here's another example:
https://github.com/libmir/mir-algorithm/blob/deb64093afa7f934956c1568358444a803d2240c/source/mir/math/sum.d#L1762

>
> [snip]
>
> I tried by using examples, but without knowing what's not clear it's hard for me to know what to do about it.

I was just thinking like some more real-world examples of how you have used it. The readme.md is good!

On Thursday, 31 January 2019 at 16:01:33 UTC, jmh530 wrote:
> On Thursday, 31 January 2019 at 14:42:43 UTC, Atila Neves wrote:
>> [snip]
>>
>> I've never had a need to use complicated values, so I haven't coded that.
>>
>> If presented with an example, I think there's a high chance I'd consider it an anti-pattern.
>
> I was thinking about something like what is in one of mir's sum unittests
> https://github.com/libmir/mir-algorithm/blob/deb64093afa7f934956c1568358444a803d2240c/source/mir/math/sum.d#L1587
> The code builds up a bunch a tuple of tuples with each containing an array and a value that the array is supposed to sum to. It then runs through them all with a foreach loop.
>
> Here's another example:
> https://github.com/libmir/mir-algorithm/blob/deb64093afa7f934956c1568358444a803d2240c/source/mir/math/sum.d#L1762

Ah. I wasn't clear, so sorry for that. Whatever is doable in CTFE you can use as an attribute. I thought you meant runtime values. This is perfectly ok:

struct Foo {
    int i;
}

Foo doubleFoo(int i) {
    return Foo(i * 2);
}

@Values(doubleFoo(42), doubleFoo(33)) unittest {}


>> I tried by using examples, but without knowing what's not clear it's hard for me to know what to do about it.
>
> I was just thinking like some more real-world examples of how you have used it. The readme.md is good!

For types, I just wrote this as part of rewriting cerealed from scratch:

@UnitTest
@Types!(
    bool, byte, ubyte, char,
    short, ushort,
    int, uint,
)
@Types!(BigEndian!DefaultOutput, LittleEndian!DefaultOutput, JSON)
void thereAndBackAgain(Type, Backend)() {
    check!((Type val) => val.cerealise!Backend.decerealise!(Type, Backend) == val);
}

8 types x 3 backends = 24 tests in very few lines of code, each of them trying 100 random values, and with the advantage that I can run just one of those 24 tests if need be, and error reporting for each of them separately.

On Friday, 1 February 2019 at 12:51:18 UTC, Atila Neves wrote:
> [snip]

I appreciate the reply. Thanks.