digitalmars.D.learn - Enabling Only Top-Level Unittests
- =?UTF-8?B?Tm9yZGzDtnc=?= (10/10) Mar 21 2016 I want to enable unittests only at the top-level of a module
- ZombineDev (4/14) Mar 21 2016 I think the easiest solution is to use
- wobbles (5/24) Mar 21 2016 This is quite annoying I feel.
- =?UTF-8?B?Tm9yZGzDtnc=?= (2/6) Mar 21 2016 I very much agree.
- =?UTF-8?B?Tm9yZGzDtnc=?= (8/15) Mar 21 2016 This is because my project has grown beyond 30klines of code and
- Adam D. Ruppe (24/27) Mar 21 2016 Note that lines of code isn't really important to build time...
- =?UTF-8?B?Tm9yZGzDtnc=?= (12/16) Apr 21 2016 These kinds of modules are very different from the ones I'm
- =?UTF-8?B?Tm9yZGzDtnc=?= (3/4) Mar 21 2016 Except implementing memoized execution of unittests into dmd.
- Anonymouse (8/18) Apr 21 2016 Version the unittests, perhaps.
- =?UTF-8?B?Tm9yZGzDtnc=?= (6/7) Apr 21 2016 This doesn't make things easier. I want to disable the builtin
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
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
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: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 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
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
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 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.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
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
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> 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
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
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
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
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: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. --- 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.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 22 2016
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 --- 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:
Apr 23 2016