Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-11 Thread Robert burner Schadek via Digitalmars-d-announce

On Friday, 11 March 2016 at 14:26:34 UTC, Atila Neves wrote:

Didn't Robert have a QuickCheck-alike as well?


Yes, https://github.com/D-Programming-Language/phobos/pull/2995




Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-11 Thread Atila Neves via Digitalmars-d-announce

On Friday, 11 March 2016 at 08:06:19 UTC, Jacob Carlborg wrote:

On 2016-03-10 12:05, Atila Neves wrote:


No, sorry. I haven't needed it yet. Something like this?


Yes.


@Types!(int, string)
void testArray(T)() {
 import std.container;

 auto arr = Array!T();
 arr.empty.shouldBeTrue;

 arr.insertBack(T.init);
 arr.empty.shouldBeFalse;
 auto l = arr.length;
 l.shouldEqual(1);
}


I'm trying to think how this would be useful. Would you want to 
test with different values than T.init? Or is there some 
library that can generate random values based on a type?


What about user defined types? T.init my not be useful at all.

I don't want to sound negative but I'm trying to see the use 
cases.


There's this: https://github.com/mcandre/dashcheck

Didn't Robert have a QuickCheck-alike as well?

Like I said, I'm not sure of the use cases, but I thought I'd 
enable it and it was fun to do. I know I've written template unit 
tests in C++ in the past, but I can't remember why.


Atila


Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-11 Thread Jacob Carlborg via Digitalmars-d-announce

On 2016-03-10 12:05, Atila Neves wrote:


No, sorry. I haven't needed it yet. Something like this?


Yes.


@Types!(int, string)
void testArray(T)() {
 import std.container;

 auto arr = Array!T();
 arr.empty.shouldBeTrue;

 arr.insertBack(T.init);
 arr.empty.shouldBeFalse;
 auto l = arr.length;
 l.shouldEqual(1);
}


I'm trying to think how this would be useful. Would you want to test 
with different values than T.init? Or is there some library that can 
generate random values based on a type?


What about user defined types? T.init my not be useful at all.

I don't want to sound negative but I'm trying to see the use cases.

--
/Jacob Carlborg


Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-10 Thread Atila Neves via Digitalmars-d-announce

On Thursday, 10 March 2016 at 16:06:38 UTC, Meta wrote:

On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:

The forum must be sick of hearing from me... :P


I'm always excited for a new release of unit-threaded


Thanks for the kind words!

Atila


Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-10 Thread Meta via Digitalmars-d-announce

On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:

The forum must be sick of hearing from me... :P


I'm always excited for a new release of unit-threaded



Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-10 Thread Atila Neves via Digitalmars-d-announce

On Thursday, 10 March 2016 at 08:09:40 UTC, Jacob Carlborg wrote:

On 2016-03-09 19:01, Atila Neves wrote:
The forum must be sick of hearing from me... :P For those not 
in the

know, unit-threaded is an advanced unit testing library for D:

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

The v0.6.3 release had tests parametrized by value; this 
v0.6.5 release
brings with it the possibility of parametrizing tests by type, 
like so:


@Types!(int, byte)
void testInit(T)() {
 assert(T.init == 0);
}

This will run the testInit code twice, once for each type, and 
report

them as separate tests:

tests.pass.attributes.testInit.int:
tests.pass.attributes.testInit.byte:


I've literally only written that silly testInit example yet. 
But imagine

how easy it'd be to test, say, different input ranges.

I'm thinking of ways of getting the parametrized tests to work 
with the
built-in unittest blocks. I assume it'll be hacky. Right now 
it's the
only thing that requires non-standard test functions and I'm 
trying to
augment the existing unit testing features of D instead of 
replacing them.


Do you have a slightly more extended example that shows how 
this is used?


No, sorry. I haven't needed it yet. Something like this?

@Types!(int, string)
void testArray(T)() {
import std.container;

auto arr = Array!T();
arr.empty.shouldBeTrue;

arr.insertBack(T.init);
arr.empty.shouldBeFalse;
auto l = arr.length;
l.shouldEqual(1);
}


Atila


Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-10 Thread Atila Neves via Digitalmars-d-announce

On Thursday, 10 March 2016 at 09:33:39 UTC, Iakh wrote:

On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:

@Types!(int, byte)
void testInit(T)() {
assert(T.init == 0);
}

Atila


It is not clear that this UDA is about unittesting


Even when attached to a test function?

Atila


Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-10 Thread Iakh via Digitalmars-d-announce

On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:

@Types!(int, byte)
void testInit(T)() {
assert(T.init == 0);
}

Atila


It is not clear that this UDA is about unittesting


Re: unit-threaded v0.6.5 - Type-parametrized tests

2016-03-10 Thread Jacob Carlborg via Digitalmars-d-announce

On 2016-03-09 19:01, Atila Neves wrote:

The forum must be sick of hearing from me... :P For those not in the
know, unit-threaded is an advanced unit testing library for D:

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

The v0.6.3 release had tests parametrized by value; this v0.6.5 release
brings with it the possibility of parametrizing tests by type, like so:

@Types!(int, byte)
void testInit(T)() {
 assert(T.init == 0);
}

This will run the testInit code twice, once for each type, and report
them as separate tests:

tests.pass.attributes.testInit.int:
tests.pass.attributes.testInit.byte:


I've literally only written that silly testInit example yet. But imagine
how easy it'd be to test, say, different input ranges.

I'm thinking of ways of getting the parametrized tests to work with the
built-in unittest blocks. I assume it'll be hacky. Right now it's the
only thing that requires non-standard test functions and I'm trying to
augment the existing unit testing features of D instead of replacing them.


Do you have a slightly more extended example that shows how this is used?

--
/Jacob Carlborg