views:

22

answers:

3

Our "main" solution is the development code: shared libraries, services, UI projects, etc. The other solution is an integration and automated tests solution. It references several of the development projects. The reason it is separate is to avoid interference with the development solution's unit test VSMDI file. And to allow us to play with different execution methods (other test runners, like Gallio or StoryTeller) without interfering with the development solution.

Recently, an interface changed in the development solution, one of our test mocks implemented that interface. But, it was not updated because there was no warning at compile time because it was in another solution. This broke our CI build.

Does anyone have a similar setup? How do you handle these issues, do you follow a strict procedure or is there some kind of technical answer?

+1  A: 

One approach would be to extract any shared interfaces into a particular directory, and then use your version control system to ensure that the directory is the same between both projects -- for example, if you were using Subversion, it has a feature called "externals" that allows one project to contain a directory that is actually a link to a specified directory (or a specified version of a specified directory) in another project.

JacobM
A: 

If your mock implements an interface from referenced project, than that project must have been built along with the rest of test projects. If it really isn't the case, check your build order/build configurations in visual studio.

It's still possible that an interface change does not trigger any compilation errors but tests do fail. But that's unrelated to solution setup.

easyCIS
A: 

I moved all my non-executing test infrastructure code into a single project. It's now in the development and test solution. This way, if development code is automatically refactored, it's changed in my project. If breaking changes are made to an interface, they'll become errors during compile.

Anthony Mastrean