including unit tests

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

including unit tests

Matthew Herrmann-2
Hi All,

I'm setting up a library structure where each library lives in its own folder,
with an accompanying unit test in the "test" subfolder. When the library
builds, I also build a unit test using the boost framework.

The problem I have is that when the user imports the project, say, "hello",
they will pull in all the link dependencies of the unit test as well. This is
problematic using Boost's unit test framework since it links in libraries
that _must_ only be used by unit test programs.

Some solutions I've thought of but dislike are :

* separate project for unit test : defeats cohesion
* change all clients to link to project using "hello//hello" syntax : ugly and
flimsy
* add aliases for every library used : maintenance and centralization issue

Has someone hit this problem before?

Thanks in advance for any help,

Matthew Herrmann

----------------

hello/Jamfile:
=======================

import testing;

project hello ;

# define the library
lib hello : .... ;

# define the unit test for hello
unit-test test
  :
   [ glob test/*.cpp ]
   /libs/boost_test
   hello
  ;

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: including unit tests

Johan Nilsson-4
Matthew Herrmann wrote:

> Hi All,
>
> I'm setting up a library structure where each library lives in its
> own folder, with an accompanying unit test in the "test" subfolder.
> When the library builds, I also build a unit test using the boost
> framework.
>
> The problem I have is that when the user imports the project, say,
> "hello", they will pull in all the link dependencies of the unit test
> as well. This is problematic using Boost's unit test framework since
> it links in libraries that _must_ only be used by unit test programs.
>
> Some solutions I've thought of but dislike are :
>
> * separate project for unit test : defeats cohesion

Why does it defeat cohesion? I usually lay out my libraries something along
the lines of this:

<proj-root>
    ...
    src
        libs
            foo
                # common Jamfile for foo would go here
                foolib
                    # Jamfile for foolib would go here
                    include
                        foo # if separate namespace
                    src
                    ...
                footest
                    # Jamfile for footest would go here
                    src
                    ...

> * change all clients to link to project using "hello//hello" syntax :
> ugly and flimsy

 You could always hide it, and use a variable to access the actual value -
e.g. $(HELLO_LIB).

> * add aliases for every library used : maintenance and centralization
> issue

Doesn't using aliases simplify maintenance? If the location and/or
definition of the lib change, you'll only have to change the alias
definition in a single place. I'm not sure what you mean by centralization
though.

[snip rest]

// Johan



_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: including unit tests

Matthew Herrmann-2
In reply to this post by Matthew Herrmann-2
Hi Johan,

Thanks for your suggestions.

> ------------------------------
>
> > * separate project for unit test : defeats cohesion
>
> Why does it defeat cohesion? I usually lay out my libraries something along
> the lines of this:
>
> <proj-root>
>     ...
>     src
>         libs
>             foo
>                 # common Jamfile for foo would go here
>                 foolib
>                     # Jamfile for foolib would go here
>                     include
>                         foo # if separate namespace
>                     src
>                     ...
>                 footest
>                     # Jamfile for footest would go here
>                     src
>                     ...

I agree this would still maintain the cohesion, but it requires 3 Jamfiles
instead of 1 for a simple project. We are developing with a lot of small
libraries, so the overhead in setting up these files would outweigh the
original complexity we were attempting to defeat.

Your other suggestions are fair and useful suggestions for projects with a few
libraries that are referred to intensively, but for a network of smaller
libraries, it creates a maintenace task to update that central list in the
Jamroot (this is the centralisation I was referring to). Also, you can't then
break out smaller hives of projects as standalone components, without
removing the references to the global constants.

For now, I've decided to just go with the slightly wordy project//target
syntax and wear the risk of users incorrectly referencing projects.

Best Regards,

Matthew Herrmann
_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build