Use unit tests in unusual architecture when porting from VS6 to VS2008?

we have one main application, which executes up to 5 different exes. These exes run independently and communicate with each other via UDP. Changing this architecture is not planned at the moment.

We want to migra开发者_如何学Cte this whole thing from VS6 to VS2008. I'm thinking about adding unit tests to make sure that after migration everything still works. Right now, there is not a single unit test.

So now I have a couple of questions:

• Which unit test framework works fine with VS6 and VS2008? CppUnit seems to work with both compilers, at least I got it running.
• How do I implement the unit tests in the above mentioned architecture? I see a problem that I have executables and no libraries, so it seems to be a bit difficult for me at that point
• Is creating the unit tests for both platforms worth the effort or do you have a simpler suggestion?

Suggestions, best practices, new ideas welcome :)

Thanks

If they communicate via UDP and you want to make sure the integration between pieces works now and later, you could write automated tests against the UDP interfaces in MSTest or NUnit in VS2008.

Write the tests in VS2008 and send input/verify output of the interfaces to the the .exe applications. Then, when you switch to .NET, just point your tests at the new endpoint for the .NET .exe and run them to verify all input and output are the same.

I think you would get more bang for your time to write the unit tests exclusively for the new app, but write tests against the external UDP interfaces to verify the migration was successful.

If you are willing to consider each of the executables as as 'module', then there is a way to introduce tests without being too invasive. This would create modules that will be a bit large for many people to be comfortable with (typical sizes when people talk about modules is a class or a source file), but your communication mechanism provides a nice way to hook in the tests.

With the architecture that you have and the fact that you don't have an existing test harness for the code, I would write a test harness that can communicate with each of the executables in isolation, using the UDP interfaces. When executing the tests, only one executable is running (besides the test code). The test code simulates the other executables by listening on their respective UDP ports and providing responses as the testcase requires. The testcase also stimulates the executable under test by sending UDP requests to it. If there is also a GUI/TUI involved, it might be needed that parts of the tests are executed manually.