Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
January 30, 2019 unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
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. |
January 30, 2019 Re: unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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?
|
January 31, 2019 Re: unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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.
|
January 31, 2019 Re: unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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. |
January 31, 2019 Re: unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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!
|
January 31, 2019 Re: unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Colin | 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!
|
January 31, 2019 Re: unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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! |
February 01, 2019 Re: unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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. |
February 01, 2019 Re: unit-threaded v0.8.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On Friday, 1 February 2019 at 12:51:18 UTC, Atila Neves wrote:
> [snip]
I appreciate the reply. Thanks.
|
Copyright © 1999-2021 by the D Language Foundation