Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Wednesday, 17 February 2016 at 09:16:02 UTC, Sebastiaan Koppe wrote: On Wednesday, 17 February 2016 at 09:05:34 UTC, Atila Neves wrote: [...] You're on a holiday, I appreciate anything you write :) [...] You don't need a testrunner generator anymore: http://forum.dlang.org/post/tgbfkazeuqrcjctye...@forum.dlang.org Atila
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Wednesday, 17 February 2016 at 09:16:02 UTC, Sebastiaan Koppe wrote: On Wednesday, 17 February 2016 at 09:05:34 UTC, Atila Neves wrote: I'm on a tablet on holiday so sorry in advance for the short answer. You're on a holiday, I appreciate anything you write :) Your versioned import is the reason why I made it so a plain string UDA is just as good as @Name. That way you only need to import unit_threaded once in a version block, and only if you want to use the shouldXXX assertions. Nice. What about @ShoudFail though? Well, then there are no miracles ;) I suggest this: version(unittest) import unit_threaded; else enum ShouldFail; // or import unit_threaded.attrs
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Wednesday, 17 February 2016 at 09:05:34 UTC, Atila Neves wrote:
I'm on a tablet on holiday so sorry in advance for the short
answer.
You're on a holiday, I appreciate anything you write :)
Your versioned import is the reason why I made it so a plain
string UDA is just as good as @Name. That way you only need to
import unit_threaded once in a version block, and only if you
want to use the shouldXXX assertions.
Nice. What about @ShoudFail though?
The test runner you mentioned can be generated by using my
dtest tool, also on dub.
I saw it, does it integrate well with `dub test` and -cov?
The next thing on my TODO list is to make it even easier to
opt-in to using unit-threaded without having to change existing
project code
I feel you are almost there.
For completeness, here is my testrunner generator that dub's
preBuildCommands calls:
void main(string[] args)
{
import std.file;
import std.algorithm : endsWith, startsWith, filter, map, joiner;
import std.array : replace;
import std.range : array;
bool onlyDFiles(DirEntry e)
{
return !e.isDir() && e.name.endsWith(".d");
}
auto files = dirEntries("source/es5",
SpanMode.depth).filter!onlyDFiles.map!("a.name").map!(`"\""~a~"\""`).joiner(",").array().replace("/",".").replace("\\",".").replace("source.","").replace(".d","");
import std.stdio;
writeln("Generating TestRunner");
auto f = File("source/testrunner.d","w");
f.write(`version (unittest)
{
bool runner()
{
import testhelpers;
import core.runtime;
return runTests!(`~files~`)(Runtime.args) == 0;
}
static this()
{
import core.runtime;
Runtime.moduleUnitTester =
}
}`);
f.close();
}
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Tuesday, 16 February 2016 at 22:13:15 UTC, Sebastiaan Koppe
wrote:
On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:
What's new:
[...]
Enjoy!
Atila
I just started using unit-threaded and I like it so far,
specially the parallel runner. Just had some speed-bumps that
might be worth noting.
Before going into details I want to mention that I am not using
it the way it is supposed to be used, which voids me from
warranty I suppose.
From what I gather the normal way would be to create separate
test-files with test-cases and unittest blocks inside them,
completely separate from normal code.
Two things that made me go in the opposite direction was dub
and code coverage.
So I don't have separate test files; I have the unittest blocks
interspersed with code. Because I don't want to include
unit_threaded in production code I ended up doing this:
version (unittest)
{
include unit_threaded;
@Name("Test test")
unittest
{
...
}
}
Which is redundant, but I need the import outside the unittest
for the UDA, and I don't want the import to show up in
production code.
Then to get `dub test` to run unit_threaded I had to create a
small program that discovers all modules and generates a
testrunner.d file in the source directory, which gets picked up
by dub. So now instead of `dub test` I call `rdmd test.d`,
which generates the testrunner.d and calls dub test.
I feel I am going against the grain here.
I'm on a tablet on holiday so sorry in advance for the short
answer. Your versioned import is the reason why I made it so a
plain string UDA is just as good as @Name. That way you only need
to import unit_threaded once in a version block, and only if you
want to use the shouldXXX assertions.
The test runner you mentioned can be generated by using my dtest
tool, also on dub.
The next thing on my TODO list is to make it even easier to
opt-in to using unit-threaded without having to change existing
project code
Atila
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
Oh, kuddos for the nice library.
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:
What's new:
[...]
Enjoy!
Atila
I just started using unit-threaded and I like it so far,
specially the parallel runner. Just had some speed-bumps that
might be worth noting.
Before going into details I want to mention that I am not using
it the way it is supposed to be used, which voids me from
warranty I suppose.
From what I gather the normal way would be to create separate
test-files with test-cases and unittest blocks inside them,
completely separate from normal code.
Two things that made me go in the opposite direction was dub and
code coverage.
So I don't have separate test files; I have the unittest blocks
interspersed with code. Because I don't want to include
unit_threaded in production code I ended up doing this:
version (unittest)
{
include unit_threaded;
@Name("Test test")
unittest
{
...
}
}
Which is redundant, but I need the import outside the unittest
for the UDA, and I don't want the import to show up in production
code.
Then to get `dub test` to run unit_threaded I had to create a
small program that discovers all modules and generates a
testrunner.d file in the source directory, which gets picked up
by dub. So now instead of `dub test` I call `rdmd test.d`, which
generates the testrunner.d and calls dub test.
I feel I am going against the grain here.
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On 9/02/2016 12:23 AM, Atila Neves wrote:
What's new:
Built-in unittest blocks can now have a name with just a string UDA:
@("test that does stuff") unittest {... }
I feel obliged to point out that this is going to be a disaster as soon
as any other library decides that means something else.
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote: What's new: Enjoy! Atila Thanks! What is the relevant link?
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On Tuesday, 9 February 2016 at 17:07:15 UTC, earthfront wrote: On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote: What's new: Enjoy! Atila Thanks! What is the relevant link? First link on DuckGo: https://github.com/atilaneves/unit-threaded
unit-threaded v0.5.7 - advanced multi-threaded unit testing library
What's new:
Built-in unittest blocks can now have a name with just a string
UDA:
@("test that does stuff") unittest {... }
Why is this important? If you just want to run unit tests in
threads and have them named, you don't need to import
unit_threaded in your source code anymore. I'm going to build on
this later with a tool to make it so that existing codebases can
benefit from unit_threaded without using it directly.
Value-parametrized tests
Have you ever written a test that looks like this?
unittest {
foreach(v; [...]) {
//test code
}
}
I have, and when it fails you have no idea which of the values
caused the failure. Now, you can do this:
@(42, 2, 3)
void testValues(int i) {
(i % 2 == 0).shouldBeTrue;
}
testValues will be run once for each value UDA with the same type
in its declaration (in this case, int). Each run will be
considered a different test and reported as such with the value
that was used. In the above case, the output will contain this:
tests.pass.attributes.testValues.42:
tests.pass.attributes.testValues.2:
tests.pass.attributes.testValues.3:
tests/pass/attributes.d:76 - Expected: true
tests/pass/attributes.d:76 - Got: false
Test tests.pass.attributes.testValues.3 failed.
Enjoy!
Atila
