I finally got around to cloning the git repo and trying the latest dub and how dub test would work.

1st of all there is a bug, should I also add it to the issue tracker on github? In any case, when the default "source" directory isn't used but explicitly named in package.json, the static imports in the autogenerated file don't have the library name before the modules, i.e. instead of "static import libname.modname" the it had "static import modname". I created a git branch for testing purposes and moved my code to "source", deleting "importPaths" and "sourcePaths" from the package.json and the code generation worked with the right static imports.


The other problem I have for my use case is that, since I'm not using the built-in unittest blocks for testing, I have testing code that can't be "turned off" by omitting -unittest. So far I've been using rdmd to figure out the test dependencies. With the actual unit test code in a different directory, dub test fails with a linker error. I don't know what the easiest way would be to tell dub to also compile and link a list of directories. Basically I need not only --main-file but also something like --extra-dirs=dir1,dir2,dir3.

Atila

What exactly does "dub test" do? Is it like running "rdmd -main
-unittest foo.d"?


It's similar. By default, for library projects, it generates a maim
module of the form
---
module test_main;
import <library_name.main_module>;
import std.stdio;
import core.runtime;

void main() { writeln("All unit tests were successful."); }
---
and runs it with build type "unittest".

It also supports setting a custom file containing main(), so that for example custom unit test runners can be specified and similar things. In
this case, the generated file looks like this:
---
module test_main;
import <library_name.main_module>;
import <custom_main_module>;
---

For packages with only executable configurations it behaves the same as
"dub run --build=unittest".

Reply via email to