www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Enabling Only Top-Level Unittests

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Mar 21 2016
next sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
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.
Mar 21 2016
parent reply wobbles <grogan.colin gmail.com> writes:
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.
Mar 21 2016
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Mar 21 2016
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Mar 21 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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 real 0m1.063s user 0m0.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 189 478 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.
Mar 21 2016
parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Apr 21 2016
prev sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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 :)
Mar 21 2016
prev sibling parent reply Anonymouse <asdf asdf.com> writes:
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.
Apr 21 2016
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Apr 21 2016
parent reply Basile B. <b2.temp gmx.com> writes:
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.
Apr 22 2016
parent Basile B <b2.temp gmx.com> writes:
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 = &tester; } --- 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).
Apr 23 2016