www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - unit-threaded v0.5.7 - advanced multi-threaded unit testing library

reply Atila Neves <atila.neves gmail.com> writes:
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
Feb 08 2016
next sibling parent reply earthfront <earthfront safetymail.info> writes:
On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:

 What's new:
 <snip>

 Enjoy!

 Atila


Thanks! What is the relevant link?
Feb 09 2016
parent earthfront <earthfront safetymail.info> writes:
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:
 <snip>

 Enjoy!

 Atila


 Thanks! What is the relevant link?


First link on DuckGo: https://github.com/atilaneves/unit-threaded
Feb 09 2016
prev sibling next sibling parent reply Daniel Murphy <yebbliesnospam gmail.com> writes:
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.
Feb 13 2016
parent Atila Neves <atila.neves gmail.com> writes:
On Saturday, 13 February 2016 at 12:41:35 UTC, Daniel Murphy 
wrote:

 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.


The  Name UDA still exists, and I think it's unlikely another 
library will be looking for string UDAs on unittest blocks that 
isn't itself a testing library.

Atila
Feb 14 2016
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Feb 16 2016
next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
Oh, kuddos for the nice library.
Feb 16 2016
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-02-16 23:13, Sebastiaan Koppe wrote:


 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.


"dub test" will generate a program that discovers all modules. Not sure 
if it's compatible with unit-threaded.

-- 
/Jacob Carlborg
Feb 16 2016
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 17 February 2016 at 07:46:51 UTC, Jacob Carlborg 
wrote:

 On 2016-02-16 23:13, Sebastiaan Koppe wrote:


 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.


 "dub test" will generate a program that discovers all modules. 
 Not sure if it's compatible with unit-threaded.


It isn't, but I found a workaround. Dub has the preBuildCommands 
which allows you to run shell commands,. It now runs my small 
util that generates a testrunner compatible with unit-threaded. 
So now its just `dub test` again. Plus I can add modules as 
arguments so only those will be tested. (e.g. dub test -- 
my.module). This is a godsend.
Feb 17 2016
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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
Feb 17 2016
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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 = &runner;
	}
}`);
	f.close();
}
Feb 17 2016
next sibling parent Atila Neves <atila.neves gmail.com> writes:
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
Feb 18 2016
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
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/tgbfkazeuqrcjctyemqz forum.dlang.org

Atila
Feb 29 2016