The following unit test in mylib.d is not run: mylib.d: 1 module mylib; 2 3 void blah() 4 { 5 } 6 unittest 7 { 8 assert(false); 9 } 10 test.d: 1 module test; 2 3 import mylib; 4 5 void main() 6 { 7 blah(); 8 } 9 Makefile: 1 test : mylib.a test.d 2 dmd -unittest test.d mylib.a 3 4 mylib.a : mylib.d 5 dmd -unittest -lib mylib.d 6 7 clean : 8 rm -f test mylib.a *.o 9 However, it WILL be run if the project is compiled as follows: dmd -unittest -c mylib.d ar -rc mylib.a mylib.o dmd -unittest test.d mylib.a
i can confirm that unittests in static librarys build by dmd does not get triggered on windows too.
*** Issue 6464 has been marked as a duplicate of this issue. ***
This needs more attention imho. If unittests are first-class citizens in D then we shouldn't have to use workarounds just to trigger them in a library.
Yeah, I also confirm this issue on Windows. Since unit testing plays an important part in software construction, I hope that it gets the attention it deserves and gets fixed soon :). Love D 4 Life.
The cause is this code in 'FuncDeclaration::toObjFile': if (multiobj && !isStaticDtorDeclaration() && !isStaticCtorDeclaration()) { obj_append(this); return; } 'multiobj' is true when -lib is passed, this unittest is then deferred to be generated later (and it *is* generated later), however it never seems to be run. Anyway a qujick fix is to add a check for lib generation: if (multiobj && !global.params.lib && !isStaticDtorDeclaration() && !isStaticCtorDeclaration()) { } This makes the unittest work, but I don't know if that's a proper fix. Any backend experts know more?
I came across this issue too, it really deserves more attentions, how about the current status?
I can confirm this issue on both Mac os x and Linux. It's a real issue when trying to write a non trivial project and using unittests.