26-Oct-2013 02:36, Daniel Davidson пишет:
On Friday, 25 October 2013 at 16:43:23 UTC, Daniel Davidson wrote:
On Friday, 25 October 2013 at 14:14:39 UTC, Dicebot wrote:
This will work starting with 2.064:
Ok. I'll keep pressing. Here is an updated version:
http://pastebin.com/g6FWsTkr
The
On Saturday, 26 October 2013 at 08:09:26 UTC, Dmitry Olshansky
wrote:
26-Oct-2013 02:36, Daniel Davidson пишет:
On Friday, 25 October 2013 at 16:43:23 UTC, Daniel Davidson
wrote:
On Friday, 25 October 2013 at 14:14:39 UTC, Dicebot wrote:
This will work starting with 2.064:
Ok. I'll keep
Here is a working solution:
https://github.com/patefacio/d-help/blob/master/d-help/opmix/ut.d
Currently it only pulls in unittests at the module level. I'm
sure it will work on unittests scoped to structs/classes, I just
need to figure out how to determine if a compile time named
object is
I strictly believe any unittest enhancing library must be built
on top of existing unittest blocks using __traits(getUnittest)
and be 100% compatible with normal `-unittest` mode
On Friday, 25 October 2013 at 13:04:03 UTC, Dicebot wrote:
I strictly believe any unittest enhancing library must be built
on top of existing unittest blocks using __traits(getUnittest)
and be 100% compatible with normal `-unittest` mode
I don't disagree. What exactly does that mean and what
On Friday, 25 October 2013 at 13:23:46 UTC, Daniel Davidson wrote:
What I'm missing, and apparently others in the original thread,
is a way to run tests selectively. It is difficult to do with
unittest because they are not named. If there were a way to
annotate the test and pull them out that
On Friday, 25 October 2013 at 13:30:54 UTC, Dicebot wrote:
You can completely re-implement default test by using runtime
hook http://wiki.dlang.org/Runtime_Hooks (_d_unittest should
do AFAIK)
*default test runner
On Friday, 25 October 2013 at 14:14:39 UTC, Dicebot wrote:
This will work starting with 2.064:
module a;
import std.stdio;
struct ID
{
string data;
}
@ID(one)
unittest
{
writeln(1);
}
@ID(two)
unittest
{
writeln(2);
}
void main()
{
import std.typetuple;
alias tests =
On Friday, 25 October 2013 at 13:04:03 UTC, Dicebot wrote:
I strictly believe any unittest enhancing library must be built
on top of existing unittest blocks using __traits(getUnittest)
and be 100% compatible with normal `-unittest` mode
I agree, this should be easy to implement. In my unit
On Friday, 25 October 2013 at 15:55:11 UTC, Gary Willoughby wrote:
For information how to implement your own unit test handler see
the bottom of the report module here:
https://github.com/nomad-software/dunit
From there you can selectively run tests based on some outside
criteria. I think
For information how to implement your own unit test handler see
the bottom of the report module here:
https://github.com/nomad-software/dunit
From there you can selectively run tests based on some outside
criteria. I think the new trait will open up further
possibilities too.
On Friday, 25 October 2013 at 14:14:39 UTC, Dicebot wrote:
This will work starting with 2.064:
Ok. I'll keep pressing. Here is an updated version:
http://pastebin.com/g6FWsTkr
The idea is to be able to just import ut, annotate as you have
described and get unit tests run. I want to mixin
On Friday, 25 October 2013 at 16:43:23 UTC, Daniel Davidson wrote:
On Friday, 25 October 2013 at 14:14:39 UTC, Dicebot wrote:
This will work starting with 2.064:
Ok. I'll keep pressing. Here is an updated version:
http://pastebin.com/g6FWsTkr
The idea is to be able to just import ut,
13 matches
Mail list logo
