Re: DUB 0.9.21 beta 1
The bug turned out to be me not using importPaths correctly,
so my bad.
On Friday, 10 January 2014 at 18:48:11 UTC, Atila Neves wrote:
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.
Re: DUB 0.9.21 beta 1
Am 09.12.2013 18:29, schrieb Kapps:
On Monday, 9 December 2013 at 12:46:00 UTC, Kapps wrote:
I was looking for something similar to dub test and am glad to see it
added, but I can't seem to figure out how to get it to do anything at
all.
Okay, it seems that this was just an issue with the beta. Building from
git master allows me to run dub test on an executable or a library
that has a main function within app.d. It would be nice to have an
automated way of running unit tests for all modules within a library
with a main file automatically generated. Even more awesome if there was
a way to integrate with tested to perform the tests. Perhaps for the
latter I could determine all files in the library with dub describe,
generate an app.d that calls tested's unit test runner on each, and then
put that app.d inside the library's source folder before invoking dub test.
The latest GIT master version now works without requiring a main file.
Regarding integration with tested, what should work now is to import
the automatically generated module test_main and use that as the
testing root:
---
import test_main;
shared static this()
{
import core.runtime;
Runtime.moduleUnitTester = () = true;
}
void main()
{
enforce(runUnitTests!test_main(new ConsoleTestResultWriter), Unit
tests failed.);
}
---
Re: DUB 0.9.21 beta 1
On Wednesday, 11 December 2013 at 09:51:37 UTC, Sönke Ludwig
wrote:
The latest GIT master version now works without requiring a
main file.
Regarding integration with tested, what should work now is to
import
the automatically generated module test_main and use that as
the
testing root:
Awesome. :)
I noticed that the main file generated seems to already support
tested integration automatically which I find quite nice.
Unfortunately it seems that tested is not actually following
imports so both the above sample and the auto-generated main
result in 0 tests being run as test_main does not directly
contain any tests. I've tried looking in to fixing this, but it's
proving a bit more tricky than expected and I won't have much
time for the next couple of days. Essentially, with static if
(__traits(compiles, { auto tup = TypeTuple!(__traits(getMember,
composite, M)); })) I don't believe that that's ever true as
assigning to tup like that is an error. Changing that to check if
the getMember succeeds will then get past that, but now the
recursive calls for runUnitTestsImpl will operate on the return
type of methods as __traits(getMember, T, somemethod) returns
the result of invoking the method and not the method itself. I'm
not sure how to pass in an alias to the actual method rather than
to the return type.
Re: DUB 0.9.21 beta 1
On Wednesday, 11 December 2013 at 22:13:59 UTC, Kapps wrote:
I noticed that the main file generated seems to already support
tested integration automatically which I find quite nice.
Unfortunately it seems that tested is not actually following
imports so both the above sample and the auto-generated main
result in 0 tests being run as test_main does not directly
contain any tests. I've tried looking in to fixing this, but
it's proving a bit more tricky than expected and I won't have
much time for the next couple of days. Essentially, with
static if (__traits(compiles, { auto tup =
TypeTuple!(__traits(getMember, composite, M)); })) I don't
believe that that's ever true as assigning to tup like that is
an error. Changing that to check if the getMember succeeds will
then get past that, but now the recursive calls for
runUnitTestsImpl will operate on the return type of methods as
__traits(getMember, T, somemethod) returns the result of
invoking the method and not the method itself. I'm not sure how
to pass in an alias to the actual method rather than to the
return type.
Ah, I think I'm mistaken. What I assumed was that it was handling
the return type of the function may have just been that it was
going over aliases instead (which in this case would have been an
alias to ulong and such, causing the above problems).
Re: DUB 0.9.21 beta 1
I was looking for something similar to dub test and am glad to see it added, but I can't seem to figure out how to get it to do anything at all. In particular, I'm trying to give tested a try as it seems quite nice and I was looking for an automated way to generate computer-readable test results (results.json in this case). According to the github page for tested, with the latest version of dub (I'm using the beta version in OSX) I should just be able to add tested as a dependency and run dub test to generate test results. I created a package called dubtest, and set app.d to contain just a unittest with @name set from tested. I then run dub test, and get: Got library for false Checking dependencies in '/Users/kapps/dev/src/dubtest' Running unit tests for package dubtest, configuration 'library'. Package dubtest (configuration library) defines no main source file, this may cause certain build modes to fail. Add an explicit mainSourceFile to the package description to fix this. Error executing command test: Main source file not found in any import path. I also tried giving my app.d a void main() which has the same result. I also tried dub test dubtest --main-file=main.d where main.d just contains a void main and writeln, but this has the same result as well. If I specifically set targetType to executable in package.json and run dub test, then I get: Got for false Building package dubtest in /Users/kapps/dev/src/dubtest Got for false Checking dependencies in '/Users/kapps/dev/src/dubtest' Running unit tests for package dubtest, configuration ''. Error executing command test: Could not resolve configuration for package tested If I use dub --build=unittest however while it's set to executable, it will successfully build and reach my main (or give a linker error if no main is present / targetType is not executable). Overall, I can't seem to get dub test to work at all regardless of configuration. Ideally I'm looking for a way to have tested run my unittests and output a results.json without manually creating a main file since these projects are generally libraries and I'm trying to automate the process for continuous integration purposes.
Re: DUB 0.9.21 beta 1
On Monday, 9 December 2013 at 12:46:00 UTC, Kapps wrote: I was looking for something similar to dub test and am glad to see it added, but I can't seem to figure out how to get it to do anything at all. Okay, it seems that this was just an issue with the beta. Building from git master allows me to run dub test on an executable or a library that has a main function within app.d. It would be nice to have an automated way of running unit tests for all modules within a library with a main file automatically generated. Even more awesome if there was a way to integrate with tested to perform the tests. Perhaps for the latter I could determine all files in the library with dub describe, generate an app.d that calls tested's unit test runner on each, and then put that app.d inside the library's source folder before invoking dub test.
Re: DUB 0.9.21 beta 1
Am 03.12.2013 19:52, schrieb Jacob Carlborg: On 2013-12-02 10:10, Sönke Ludwig wrote: Using dub test --main-file= See also dub test --help. * Can this be specified in the package.json file so invoking dub test will always use a custom main file? Not in a nice way, but I'd suggest we do something like making dub test look for a configuration named unittest before trying to generate its own custom main. * Don't know how it works now but it would be nice if dub could pass all remaining command line arguments to the custom main function It does already: dub test -- args...
Re: DUB 0.9.21 beta 1
On 2013-12-04 10:57, Sönke Ludwig wrote: Not in a nice way, but I'd suggest we do something like making dub test look for a configuration named unittest before trying to generate its own custom main. That would be nice to have. It does already: dub test -- args... Cool. -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
It also supports setting a custom file containing main(), so that for example custom unit test runners can be specified and similar Awesome! 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. So custom_main_module defines the main function to be executed?
Re: DUB 0.9.21 beta 1
Am 03.12.2013 10:34, schrieb Atila Neves: It also supports setting a custom file containing main(), so that for example custom unit test runners can be specified and similar Awesome! 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. So custom_main_module defines the main function to be executed? Exactly. main() will usually be empty, as unit tests by default run before main() is called, but it can be used to disable the standard Runtime.moduleUnitTester and do something customized.
Re: DUB 0.9.21 beta 1
On 2013-12-02 10:10, Sönke Ludwig wrote: Using dub test --main-file= See also dub test --help. * Can this be specified in the package.json file so invoking dub test will always use a custom main file? * Don't know how it works now but it would be nice if dub could pass all remaining command line arguments to the custom main function -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
Am 02.12.2013 08:32, schrieb Jacob Carlborg:
On 2013-11-30 21:48, Sönke Ludwig wrote:
Based on the bug reports so far, I've prepared a new beta release of
0.9.21 for testing. Apart from fixes for the reported issues, it
contains a revamped command line interface with detailed help for each
command and also the new dub test command.
http://code.dlang.org/download
https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md
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.
Re: DUB 0.9.21 beta 1
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 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?
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?
--
/Jacob Carlborg
Re: DUB 0.9.21 beta 1
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.
Re: DUB 0.9.21 beta 1
On 2013-12-02 10:10, Sönke Ludwig wrote: 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. I don't know why a main module is required for libraries in the first place. It doesn't make sense. It's perfectly fine to have a library consisting of two files which don't import each other. This must be supported. To me, for libraries, it would make most sense to just specify a directory and it would compile all those files in that directory. Using dub test --main-file= See also dub test --help. I see. 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. For any testing tool worthy its name I would at least expect to be able to use it like this: $ dub test ./directory Runs all test in the given directory, recursively $ dub test foo.d Runs all test in the given file -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
Am 02.12.2013 17:01, schrieb Jacob Carlborg: On 2013-12-02 10:10, Sönke Ludwig wrote: 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. I don't know why a main module is required for libraries in the first place. It doesn't make sense. It's perfectly fine to have a library consisting of two files which don't import each other. This must be supported. To me, for libraries, it would make most sense to just specify a directory and it would compile all those files in that directory. I need to dig up the old discussions about this topic, I just seemed to remember that we reached a conclusion to require a root file also for libraries, but you are right that technically it's not required in this case (as in the the suggested alternative). Using dub test --main-file= See also dub test --help. I see. 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. For any testing tool worthy its name I would at least expect to be able to use it like this: $ dub test ./directory Runs all test in the given directory, recursively $ dub test --root=./directory This doesn't work recursively, but a --recursive switch may be a good idea to add. $ dub test foo.d Runs all test in the given file Since DUB operates on packages and I don't really see the compelling advantage over rdmd -main -unittest foo.d, I'd rather not complicate it further for this use case. An exception would be if foo is a single file package (yet to be implemented).
Re: DUB 0.9.21 beta 1
On 2013-12-02 21:51, Sönke Ludwig wrote: I need to dig up the old discussions about this topic, I just seemed to remember that we reached a conclusion to require a root file also for libraries, but you are right that technically it's not required in this case (as in the the suggested alternative). Please let me know if you find it. Since DUB operates on packages and I don't really see the compelling advantage over rdmd -main -unittest foo.d, I'd rather not complicate it further for this use case. An exception would be if foo is a single file package (yet to be implemented). Fair enough. -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
On 2013-11-30 21:48, Sönke Ludwig wrote: Based on the bug reports so far, I've prepared a new beta release of 0.9.21 for testing. Apart from fixes for the reported issues, it contains a revamped command line interface with detailed help for each command and also the new dub test command. http://code.dlang.org/download https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md What exactly does dub test do? Is it like running rdmd -main -unittest foo.d? -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
Based on the bug reports so far, I've prepared a new beta release of 0.9.21 for testing. Apart from fixes for the reported issues, it contains a revamped command line interface with detailed help for each command and also the new dub test command. http://code.dlang.org/download https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md
Re: DUB 0.9.21 beta 1
On Saturday, 30 November 2013 at 20:49:14 UTC, Sönke Ludwig wrote: Based on the bug reports so far, I've prepared a new beta release of 0.9.21 for testing. Apart from fixes for the reported issues, it contains a revamped command line interface with detailed help for each command and also the new dub test command. http://code.dlang.org/download https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md So, is it beta or release? :) (Should I package it already?)
