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