www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Running unittests in a D library

reply "Chris Molozian" <chris cmoz.me> writes:
Hey all,

I'm sure that this is a rather daft question but I've tried to 
search the d.learn mailing list and must have missed a question 
about it.

I've read the unit testing documentation on dlang.org and I know 
that `unittest { /* some code */ }` blocks are compiled into the 
executable and executed after static initialization and before 
the main() function is called. This makes sense in an application 
but how does this apply to a library?

For example, writing a D library using DMD's `-lib` compiler 
flag, how do I run the unit tests in the generated library?

Cheers,

Chris
Sep 19 2012
next sibling parent "Chris Molozian" <chris cmoz.me> writes:
Actually after more digging it seems that unit testing libraries 
in D doesn't work.

It seems pretty bad that in 2012 with unit testing a huge part of 
the software development process and D describing itself as a 
language with unit testing built in, this bug report / feature 
request hasn't been addressed:

http://d.puremagic.com/issues/show_bug.cgi?id=4669

Is there any update on the status of this enhancement? Is there a 
recommended workaround to unit test a D library?

Cheers,

Chris


On Wednesday, 19 September 2012 at 18:49:12 UTC, Chris Molozian 
wrote:
 Hey all,

 I'm sure that this is a rather daft question but I've tried to 
 search the d.learn mailing list and must have missed a question 
 about it.

 I've read the unit testing documentation on dlang.org and I 
 know that `unittest { /* some code */ }` blocks are compiled 
 into the executable and executed after static initialization 
 and before the main() function is called. This makes sense in 
 an application but how does this apply to a library?

 For example, writing a D library using DMD's `-lib` compiler 
 flag, how do I run the unit tests in the generated library?

 Cheers,

 Chris
Sep 19 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, September 19, 2012 20:50:08 Chris Molozian wrote:
 Hey all,
 
 I'm sure that this is a rather daft question but I've tried to
 search the d.learn mailing list and must have missed a question
 about it.
 
 I've read the unit testing documentation on dlang.org and I know
 that `unittest { /* some code */ }` blocks are compiled into the
 executable and executed after static initialization and before
 the main() function is called. This makes sense in an application
 but how does this apply to a library?
 
 For example, writing a D library using DMD's `-lib` compiler
 flag, how do I run the unit tests in the generated library?
You don't build it as a library when your unit testing it. You create an empty main, compile it all as an executable, and run it. I believe that rdmd --main will do this for you (rdmd comes with dmd), but I haven't really used rdmd, so I'm not 100% certain. - Jonathan M Davis
Sep 19 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-19 21:34, Jonathan M Davis wrote:

 You don't build it as a library when your unit testing it. You create an empty
 main, compile it all as an executable, and run it. I believe that rdmd --main
 will do this for you (rdmd comes with dmd), but I haven't really used rdmd, so
 I'm not 100% certain.
The problem in that bug report is you can't first compile your library as a library and then compile an executable using the library. According to the bug report it won't run the unittest blocks from the library. -- /Jacob Carlborg
Sep 19 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 19, 2012 21:49:19 Jacob Carlborg wrote:
 On 2012-09-19 21:34, Jonathan M Davis wrote:
 You don't build it as a library when your unit testing it. You create an
 empty main, compile it all as an executable, and run it. I believe that
 rdmd --main will do this for you (rdmd comes with dmd), but I haven't
 really used rdmd, so I'm not 100% certain.
The problem in that bug report is you can't first compile your library as a library and then compile an executable using the library. According to the bug report it won't run the unittest blocks from the library.
Yes. But the solution then is to not unit test your library that way. You build it as a binary with an empty main and run that. It may be that compiling it as a library and then linking should work, but unless you want to have the unit test stuff compiled into your library normally (I wouldn't think so), you'll have to compile it separately for unit testing anyhow, so I don't think that it's really a big issue. You just have to realize that you need to not compile your library as a library when compiling your -unittest build. - Jonathan M Davis
Sep 19 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-20 01:56, Jonathan M Davis wrote:

 Yes. But the solution then is to not unit test your library that way. You
 build it as a binary with an empty main and run that. It may be that compiling
 it as a library and then linking should work, but unless you want to have the
 unit test stuff compiled into your library normally (I wouldn't think so),
 you'll have to compile it separately for unit testing anyhow, so I don't think
 that it's really a big issue. You just have to realize that you need to not
 compile your library as a library when compiling your -unittest build.
Of course you don't want the unit tests in a release build, but when you explicitly build with -unittest or -debug they could be included. -- /Jacob Carlborg
Sep 19 2012
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 19 Sep 2012 12:34:18 -0700
schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 On Wednesday, September 19, 2012 20:50:08 Chris Molozian wrote:
 Hey all,
 
 I'm sure that this is a rather daft question but I've tried to
 search the d.learn mailing list and must have missed a question
 about it.
 
 I've read the unit testing documentation on dlang.org and I know
 that `unittest { /* some code */ }` blocks are compiled into the
 executable and executed after static initialization and before
 the main() function is called. This makes sense in an application
 but how does this apply to a library?
 
 For example, writing a D library using DMD's `-lib` compiler
 flag, how do I run the unit tests in the generated library?
You don't build it as a library when your unit testing it. You create an empty main, compile it all as an executable, and run it. I believe that rdmd --main will do this for you (rdmd comes with dmd), but I haven't really used rdmd, so I'm not 100% certain. - Jonathan M Davis
But it should be possible. A pointer to the unittests is kept in the ModuleInfo so you'd have to get all the module infos of the library. There's actually no reason it wouldn't work, static libraries are just an archive of .o files. But the compiler must explicitly disable unittests when it's called with "-lib" as this example shows: test1.d ----- import std.stdio; unittest { writeln("test1.unittest"); } ----- main.d ----- import test1; void main(){} ----- dmd -lib test1.d -unittest dmd main.d -unittest test1.a ./main //no output dmd -c test1.d -unittest dmd main.d -unittest test1.o ./main //OK dmd -c test1.d -unittest ar r test1.a test1.o dmd main.d -unittest test1.a ./main //OK The problem is this: Druntime must be able to get a reference to the ModuleInfo. So the linker must not remove the unittests in the library, so it might be necessary to import all modules with unittests from main.d. This situation sucks, but it could get better with shared libraries: If a shared lib is built with --unittest all unittest functions are compiled in. We don't have to worry about the linker removing stuff for dynamic libraries. Then a unittest runner could dlopen the library, search for all ModuleInfos (this is a little diffficult, but we'll need it for plugins/reflection anyway) and run all unittests in the library.
Sep 20 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote:
 But it should be possible.
I'm not arguing that it shouldn't be possible. I'm just pointing out that it wouldn't really be useful. You have to build at least two versions of your library anyway (one with -unittest and one without), so being forced to build your library as a binary for unit tests really isn't a big deal IMHO. But I have no problem with it working to link in a library built with -unittest and have its unit tests run. - Jonathan M Davis
Sep 20 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-20 13:14, Jonathan M Davis wrote:
 On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote:
 But it should be possible.
I'm not arguing that it shouldn't be possible. I'm just pointing out that it wouldn't really be useful. You have to build at least two versions of your library anyway (one with -unittest and one without), so being forced to build your library as a binary for unit tests really isn't a big deal IMHO. But I have no problem with it working to link in a library built with -unittest and have its unit tests run.
You'll most likely have a release and debug version anyway. Just put the unit tests in the debug version. -- /Jacob Carlborg
Sep 20 2012
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
On Thursday, 20 September 2012 at 18:31:38 UTC, Jacob Carlborg 
wrote:
 On 2012-09-20 13:14, Jonathan M Davis wrote:
 On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote:
 But it should be possible.
I'm not arguing that it shouldn't be possible. I'm just pointing out that it wouldn't really be useful. You have to build at least two versions of your library anyway (one with -unittest and one without), so being forced to build your library as a binary for unit tests really isn't a big deal IMHO. But I have no problem with it working to link in a library built with -unittest and have its unit tests run.
You'll most likely have a release and debug version anyway. Just put the unit tests in the debug version.
I have the same issue. My point is related to IDE usage, I need provide a library for my samples projects and for users. I don't want have to create 2 projects of my "library" one with a main and one without, because in this case each time I add or remove a file I need do this manipulation for both projects. I try the "-main" option of dmd that need "add default main() (e.g. for unittesting)", reading it like that I though it was exactly to be able to put a library project as executable. PS : I am using VisualD and MonoD. I also searched if it is possible to create one d file that imports all my library sources just like we do with a #include "build-all.c". Sadly we can't create a Visual project that contains only D sources without any building steps, instead we could put this project of files references as dependency. All samples projects would be build with the library code.
Nov 08 2013
parent "Flamaros" <flamaros.xavier gmail.com> writes:
On Friday, 8 November 2013 at 20:29:19 UTC, Flamaros wrote:
 On Thursday, 20 September 2012 at 18:31:38 UTC, Jacob Carlborg 
 wrote:
 On 2012-09-20 13:14, Jonathan M Davis wrote:
 On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote:
 But it should be possible.
I'm not arguing that it shouldn't be possible. I'm just pointing out that it wouldn't really be useful. You have to build at least two versions of your library anyway (one with -unittest and one without), so being forced to build your library as a binary for unit tests really isn't a big deal IMHO. But I have no problem with it working to link in a library built with -unittest and have its unit tests run.
You'll most likely have a release and debug version anyway. Just put the unit tests in the debug version.
I have the same issue. My point is related to IDE usage, I need provide a library for my samples projects and for users. I don't want have to create 2 projects of my "library" one with a main and one without, because in this case each time I add or remove a file I need do this manipulation for both projects. I try the "-main" option of dmd that need "add default main() (e.g. for unittesting)", reading it like that I though it was exactly to be able to put a library project as executable. PS : I am using VisualD and MonoD. I also searched if it is possible to create one d file that imports all my library sources just like we do with a #include "build-all.c". Sadly we can't create a Visual project that contains only D sources without any building steps, instead we could put this project of files references as dependency. All samples projects would be build with the library code.
I find a way by adding new build configuration that allow my to build an executable binary and run unittests of my "library". This solution works well with VisualD, but it stuck with MonoD, because new configuration can't be selected to run it.
Nov 08 2013
prev sibling parent "Nathan M. Swan" <nathanmswan gmail.com> writes:
On Wednesday, 19 September 2012 at 18:49:12 UTC, Chris Molozian 
wrote:
 Hey all,

 I'm sure that this is a rather daft question but I've tried to 
 search the d.learn mailing list and must have missed a question 
 about it.

 I've read the unit testing documentation on dlang.org and I 
 know that `unittest { /* some code */ }` blocks are compiled 
 into the executable and executed after static initialization 
 and before the main() function is called. This makes sense in 
 an application but how does this apply to a library?

 For example, writing a D library using DMD's `-lib` compiler 
 flag, how do I run the unit tests in the generated library?

 Cheers,

 Chris
$ rdmd --main -unittest (other compiler flags) (source files)
Sep 19 2012