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

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

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

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

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

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)

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

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.

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

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