Am 02.12.2013 09:19, schrieb Jacob Carlborg:
> On 2013-12-02 09:10, Sönke Ludwig wrote:
>
>> 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".
>
> What if there isn't a main module for the library?
It errors out. An alternative would be to put _all_ source files as
static imports into the generated module, but the main file will also be
required for dependency based builds (--rdmd and possibly for DUB's own
build system, once partial rebuilds work), so I figured it would be a
good idea to already add it now and make sure that most projects have
one when/if it gets important.
>
>> 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>;
>> ---
>
> How is the custom file specified?
Using "dub test --main-file=...". See also "dub test --help".
>
>> For packages with only executable configurations it behaves the same as
>> "dub run --build=unittest".
>
> This doesn't support having the unit tests in a separate folder?
>
Unit tests in a separate folder can for example have their own package
description file and be handled separately. But "dub test" like it is
now is just the minimal beginning, everything else still needs to be
figured out/defined, ideas and opinions are welcome.
