Re: [Boost-users] [Test] Glue for Visual Studio automated unit testing

From: Eames, Andrew (andrew_at_[hidden])
Date: 2008-07-21 10:15:01

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_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Stephen Nuchia
Sent: Wednesday, July 16, 2008 11:35 AM
To: boost-users_at_[hidden]
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

 

________________________________

Spam
<http://mail-gw.cognex.com/canit/b.php?c=s&i=12255605&m=7b9a851639f6> 
Not spam
<http://mail-gw.cognex.com/canit/b.php?c=n&i=12255605&m=7b9a851639f6> 
Forget previous vote
<http://mail-gw.cognex.com/canit/b.php?c=f&i=12255605&m=7b9a851639f6>