We’ve done something very similar to this. We don’t use the boost
test framework (at least not yet) but we have our own unit test framework for
unmanaged C++. By using platform dependent macros for defining test methods
etc., we can compile our unit tests as either native C++ for platform xyz or as
managed C++ unit tests for VS– no wrappers required
Andrew
From: boost-users-bounces@lists.boost.org
[mailto:boost-users-bounces@lists.boost.org] On Behalf Of Stephen Nuchia
Sent: Wednesday, July 16, 2008 11:35 AM
To: boost-users@lists.boost.org
Subject: [Boost-users] [Test] Glue for Visual Studio automated unit
testing
Visual
Studio 2008, in the pricier editions, has rich support for automated unit
testing – of “managed” code units. Not much help with 4 million lines of
native code!
I’ve
set up unit test projects within my overall solution. These build
executables from source (using boost-test’s default main() ) and run them using
custom build step scripts. It’s simple and it works but it does not tie
into the test automation infrastructure. Test failures show up as build
failures, and there’s no direct support for things like test coverage analysis.
It
turns out, however, that if what you want to test has a COM or .NET interface,
you can write a C# (or managed C++) test driver, reference the interface
exported by the native code, and test away. But that doesn’t help you
unit test traditional libraries.
What
I’d like to do is to develop a .NET-visible wrapper for a boost-test unit test
driver. This would allow us to author the actual tests in native C++
using boost-test, build and run the test suite as before if desired. We
could, for instance, execute the test driver under the debugger to investigate
a failure. But we could also drive the tests from a Visual Studio Test
project. The simple thing to do would be to make each native test driver
(with its entire suite of tests) one Studio-level test. It might be
possible to expose the internal boost-test suite structure to the wrapper so
the individual tests show up in the database; I’m not sure this is desirable
and it would be more work.
My
main purpose in posting this note is to see if anybody out there is interested
in working with me on this. Secondarily, I’d appreciate any advice from
those more familiar with the guts of boost-test. What is the best place
to hook in and what features does the exported interface (object model) need to
expose?
Because
this effort targets special features found only in high-end versions of visual
studio, it will not be of much interest to the majority of the readers of this
list. I suggest folks send me email directly unless you think everyone
needs to see it.
-swn