One of the items that I have not gotten to talk about in my recent sessions on test driven development is in the area of integration testing. I have been focusing on ‘core developer values’ that work hand in hand with unit testing for the most part.  In particular, at my last consulting project before coming to my current role, I did quite a lot of automated integration testing using NUnit. The pattern is common:    

• Client Application - talks to N services.   

• Each server application has it’s level of volatility and own release schedule.   

• The quality of the server applications varies (sadly, depending on where you are!).   

• Client application has some kind of client side facade or proxy that hides the mechanics of dealing with the service/ server application.   

Not only is it important to have unit test style code testing automation, but actually doing the integration testing in an automated way can bring great value. Typically - it is ‘nasty’ to talk to a database, messing service, web service, etc. from a proper unit test. Unit tests want to make sure that you are dealing with the abstractions immediately adjacent to your class under test. Any real external dependencies like databases etc are normally stubbed or mocked out.  At some point you need to ACTUALLY test the real interaction of the tiers however. Thankfully - the unit testing tools are excellent at containing the automated tests and running them. There is a common model then between your unit tests and your integration tests. In practice what I have done is to have an extra package for integration tests. This extra package is not deployed of course. It may be 1 package per target assembly or 1 package for several assemblies depending normally on how the binaries are used - if 3 binaries are used together always then you can have 1 integration test package for example. I am generally in favor however of 1 target assembly, 1 unit test assembly (with internals visible to) and one integration test assembly (also with internals visible to). Now I have my clean core code, my unit tests and my integration tests.  Server side applications need to deploy some regular ‘integration builds’ that can be run again for integration testing. Server applications in practice may also have other service applications they depend on. In this scenario -they will also benefit from an automated integration testing strategy.