Re: Enabling Only Top-Level Unittests
On Friday, 22 April 2016 at 18:18:39 UTC, Basile B. wrote:
I think a DMD option should be added to allow the tests to be
compiled but never called, something like -runTests. Because
the first solution is much more attractive.
Actually the first solution works with:
https://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester
---
#!runnable-flags: -unittest -main
module m;
import std.stdio;
import core.runtime;
enum USERTEST;
@USERTEST unittest // exeuted once
{
writeln("bang");
}
unittest
{
writeln("bing");
}
bool tester()
{
import std.traits;
foreach(t; __traits(getUnitTests, m))
{
static if (hasUDA!(t, USERTEST))
t();
}
return true;
}
static this()
{
Runtime.moduleUnitTester =
}
---
So there's really no problem with selecting the top-level UT.
Maybe it even works with other traits such as "parent". Or with a
template that collects only the tests in a set of module like in
the previous attempt (based on this:
http://stackoverflow.com/questions/35075253/is-it-possible-to-compile-unittest-without-running-them-and-explicitly-run-unitt/35086752#35086752).
Re: Enabling Only Top-Level Unittests
On Thursday, 21 April 2016 at 19:38:21 UTC, Nordlöw wrote:
On Thursday, 21 April 2016 at 12:35:42 UTC, Anonymouse wrote:
Then dmd -unittest -version=TestDeps if you want them run.
This doesn't make things easier. I want to disable the builtin
unittests of the modules I've imported. This requires me to add
a
version(test_MODULE) unittest
in each module named MODULE.
This is really inconvenient.
You could anotate your user/top level tests and select only those
with __traits(getUnittest,...) and hasUDA(). Unfortunately it
seems that there's a flaw because in a program all the tests will
be automatically executed once then again those that are anotated.
---
#!runnable-flags: -unittest
module m;
import std.stdio;
enum USERTEST;
@USERTEST unittest // exeuted twice
{
writeln("bang");
}
unittest // executed once
{
writeln("bing");
}
void main(string[] args)
{
import std.traits;
foreach(t; __traits(getUnitTests, m))
{
static if (hasUDA!(t, USERTEST))
t();
}
}
---
But...
A solution that would work for both a library and a program is
this:
---
module m;
import std.stdio;
enum USERTEST;
@USERTEST void test0()
{
writeln("bing");
}
@USERTEST void test1()
{
writeln("bang");
}
unittest
{
// not even compiled
}
void runUserTests(Modules...)()
{
import std.traits;
static if (Modules.length > 1)
runModuleTests!(Modules[1..$]);
else static if (Modules.length == 1)
{
foreach(member; __traits(allMembers, Modules[0]))
foreach(o; __traits(getOverloads, Modules[0], member))
static if (hasUDA!(o, USERTEST) &&
(Parameters!o).length == 0)
o();
}
}
void main()
{
runUserTests!m;
}
---
I think a DMD option should be added to allow the tests to be
compiled but never called, something like -runTests. Because the
first solution is much more attractive.
Re: Enabling Only Top-Level Unittests
On Thursday, 21 April 2016 at 12:35:42 UTC, Anonymouse wrote: Then dmd -unittest -version=TestDeps if you want them run. This doesn't make things easier. I want to disable the builtin unittests of the modules I've imported. This requires me to add a version(test_MODULE) unittest in each module named MODULE. This is really inconvenient.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote:
I want to enable unittests only at the top-level of a module
compilation.
If I have a module
top.d
that imports
dep1.d
dep2.d
...
which all contain unittests, how do I compile top.d with only
the unittests for top.d enabled?
Version the unittests, perhaps.
module depN;
version (TestDeps)
unittest {
// ...
}
Then dmd -unittest -version=TestDeps if you want them run.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 15:25:29 UTC, Adam D. Ruppe wrote: Yes, compiling 33,000 lines from my libs happened in about one second. My experience with slow D builds tends to be that it is caused by CTFE, not by scale. These kinds of modules are very different from the ones I'm working on. Especially the ones in https://github.com/nordlow/phobos-next This because many of my algorithms/ranges/containers are unittested with lots of combinations of template parameters (types) for robustness. This inevitable requires lots of CT-logic evaluation and of course takes long to compile. A compiler switch would significantly lower the iteration time in my workflow. 5-10 seconds => ~ 1 second. Could somebody at least outline where in the DMD source I should start digging for this?
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 15:15:41 UTC, Nordlöw wrote: This is because my project has grown beyond 30klines of code and at that scale not even D's speed is enough for getting fast incremental builds through dmd. Note that lines of code isn't really important to build time... $ time dmd -c -o- dom.d cgi.d web.d sha.d libssh2.d simpledisplay.d color.d minigui.d terminal.d characterencodings.d real0m1.063s user0m0.986s sys 0m0.075s $ wc dom.d cgi.d web.d sha.d libssh2.d simpledisplay.d color.d minigui.d terminal.d characterencodings.d 6645 22789 173999 dom.d 3994 16063 123572 cgi.d 4921 18287 143876 web.d 412 1407 10066 sha.d 189478 5357 libssh2.d 8850 34060 274340 simpledisplay.d 1163 4413 27268 color.d 2785 8150 70996 minigui.d 3834 13888 114827 terminal.d 473 2819 18391 characterencodings.d 33266 122354 962692 total Yes, compiling 33,000 lines from my libs happened in about one second. My experience with slow D builds tends to be that it is caused by CTFE, not by scale.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 15:15:41 UTC, Nordlöw wrote: I don't see any other solution for really large projects. Except implementing memoized execution of unittests into dmd. Which I have discussed previously :)
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 15:11:31 UTC, Nordlöw wrote: On Monday, 21 March 2016 at 11:36:10 UTC, wobbles wrote: This is quite annoying I feel. There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths. I very much agree. This is because my project has grown beyond 30klines of code and at that scale not even D's speed is enough for getting fast incremental builds through dmd. Therefore I've split my project into separate build using scons. With good dependency design I've reduced the build time from around 12 (via one single call to dmd) to 2 seconds. I don't see any other solution for really large projects.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 11:36:10 UTC, wobbles wrote: This is quite annoying I feel. There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths. I very much agree.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 10:37:31 UTC, ZombineDev wrote: On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote: I want to enable unittests only at the top-level of a module compilation. If I have a module top.d that imports dep1.d dep2.d ... which all contain unittests, how do I compile top.d with only the unittests for top.d enabled? I think the easiest solution is to use http://dlang.org/spec/traits.html#getUnitTests and to run the tests you want manually. This is quite annoying I feel. There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote: I want to enable unittests only at the top-level of a module compilation. If I have a module top.d that imports dep1.d dep2.d ... which all contain unittests, how do I compile top.d with only the unittests for top.d enabled? I think the easiest solution is to use http://dlang.org/spec/traits.html#getUnitTests and to run the tests you want manually.
