RejectedSoftware Forums

Sign up

Vibe.d unittests

How do you normally run those?

I get a segmentation fault in mutex constructor when running this typical command:
"rdmd --main --unittest vibe/db/mongo/connection.d"

Re: Vibe.d unittests

Am 26.01.2013 20:45, schrieb Dicebot:

How do you normally run those?

I get a segmentation fault in mutex constructor when running this typical command:
"rdmd --main --unittest vibe/db/mongo/connection.d"

I think it's missing some static initialization. These days I do dub --build=unittest, but
DFLAGS="-g -debug -unittest" vibe run from any of the example applications should also do it.

Re: Vibe.d unittests

On Sat, 26 Jan 2013 21:12:42 +0100, Sönke Ludwig wrote:

I think it's missing some static initialization. These days I do dub --build=unittest, but
DFLAGS="-g -debug -unittest" vibe run from any of the example applications should also do it.

Thanks, works for me. Another question regarding ongoing mongo proposal: I will most likely have sample project for sanity tests with mongod running. Remember you had a plans for a CI so this may be worth committing too in some form. Have you though about how sanity/functional test should look within CI yet?

Sorry for all tediousness but I have quite a long-term plans for vibe.d thus personally interested in doing everything right ;)

Re: Vibe.d unittests

On Sat, 26 Jan 2013 20:33:08 GMT, Dicebot wrote:

On Sat, 26 Jan 2013 21:12:42 +0100, Sönke Ludwig wrote:

I think it's missing some static initialization. These days I do dub --build=unittest, but
DFLAGS="-g -debug -unittest" vibe run from any of the example applications should also do it.

Thanks, works for me. Another question regarding ongoing mongo proposal: I will most likely have sample project for sanity tests with mongod running. Remember you had a plans for a CI so this may be worth committing too in some form. Have you though about how sanity/functional test should look within CI yet?

Sorry for all tediousness but I have quite a long-term plans for vibe.d thus personally interested in doing everything right ;)

So far I loosely had the plan to make a separate directory for higher level and performance tests and put the tests there as normal functions. However, from there to a nicely CI integrated solution is obviously still some way.

Maybe for now something like this:

vibe.d/
	test/
		source/
			app.d
			test_xx.d
			test_xy.d
		package.json

And app.d simply run the tests sequentially, e.g.:

import std.stdio;
import test_xx.d;
import test_xy.d;

void runTest(alias F)()
{
	string status = "OK";
	try F();
	catch status = "ERR";
	writefln("%s: %s", F.stringof, status);
}

void main()
{
	// iterate over all tests and call runTest
}

Later that could be extended with better diagnostics, performance measurements and some kind of structured output for nice display on the CI server.

** I recognize that this approach does not enforce test isolation, so the results may sometimes not be accurate. However, the alternative of compiling each test separately would incur a considerable hit on the CI compute resources.