From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-30 12:04:29
> "Tanner Davis" <tanner.davis_at_[hidden]> wrote in message
> news:6704.32919073409$1180477224_at_news.gmane.org...
> Hello-
Hi, Tanner
> What is the best practice for embedding test cases into library (versus
> executable) projects? I have successfully used the Boost.Test framework
> to build and
> create EXE targeted, testing specific (MSVS) projects. However, much of
> what I need to unit-test is compiled into a Win32 DLLs, and I would much
> rather > embed the test cases directly within that DLL project code
> (inside define blocks of course), rather than having to define a separate
> project to produce an EXE
> to execute the tests for each DLL. When I say "I would rather", it
> really means my manager demands it. It appears that the boost.test MACROs
> nicely
> obfuscate the normal main()-ish entry point for the testing. I have
> searched for information on overriding or extending the kick-off of
> whatever calls the
> init_unit_test_suite() so I could write my own custom entry points for
> testing the DLL as a post-build step, but have not found what I am looking
> for.
Boost 1.34.0 introduced new Boost.Test variant usage specifically for this
case. It's called "external test runner usage variant". The idea is to build
your test module as DLL (define BOOST_TEST_DYN_LINK during compilation). Now
you can run the test modult using any external test runner tool. Boost.Test
supply simple command line test runner: boost_test_runner utility (it's
located in libs/test). What it does essenciallty is it loads DLL
dynamically, init the framework
and test tree and run all the registerred test cases.
> So, my question is this. Is there a provided framework for testing code
> within a DLL project? And if not, is there a way to kick start the
> testing from a non-
> main method (say a custom DLL entry point), and would this strategy work
> within the confines of Boost.Test? I believe that other well known unit
> testing
> framework (which shall remain nameless) supports such a thing, and I would
> suspect Boost.Test does also.
>
> I apologize if this question is often asked or obviously documented
> elsewhere.
> Thank you for the assistance.
The upcoming docs will cover this usage vasriants in more details.
HTH,
Gennadiy