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"
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"
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
, butDFLAGS="-g -debug -unittest" vibe
run from any of the example applications should also do it.
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
, butDFLAGS="-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 ;)
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
, butDFLAGS="-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.