[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
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 ________________________________ 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>
Stephen Nuchia <snuchia <at> statsoft.com> writes:
What I’d like to do is to develop a .NET-visible wrapper for a boost-test unit test driver.
It would be great undertaking! I am really interesting in these kind of projects. In 1.34 I've made changes to the Boost.Test specifically designed to simplify and streamline these.
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?
I am ready to help you with any issues/questions related to Boost.Test. you can contact me directly on my gmail account. Gennadiy
participants (3)
-
Eames, Andrew -
Gennadiy Rozental -
Stephen Nuchia