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.
