According to Wikipedia

‘Integration testing’ (sometimes called Integration and Testing, abbreviated I&T) is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing.

Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

Strategies

You can do integration testing in a variety of ways but the following are three common strategies:

· The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

· The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality.

· The third approach, sometimes referred to as the umbrella approach, requires testing along functional data and control-flow paths. First, the inputs for functions are integrated in the bottom-up pattern discussed above. The outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the degree of support for early release of limited functionality. It also helps minimize the need for stubs and drivers. The potential weaknesses of this approach are significant, however, in that it can be less systematic than the other two approaches, leading to the need for more regression testing.

Finding a Tool

While trying to find a good framework for integration testing I came across FIT framework for integration testing , but considering the amount of support and documentation available for the framework I decided not to investigate it further. So using Nunit for Integration testing seems to be the best way to go about doing integration testing at this time.

In order to use Nunit for Integration testing I found one good blog post here and another one here however it does not give a definite answer of what’s the best way to go about Integration testing.

Spring framework gives some guidance how to use integration testing for the database objects and spring objects but I think for the moment if we mock up the spring framework tests then we should be fine.

In case of using Nunit to do integration testing , and keep the tests separate there are two suggested methodologies

1. Categories the Integration tests and Modular tests separately and then one can use Nunit to test each category.

2. Keep two projects separately one, for Unit tests and one for integration tests.

http://www.testdriven.net/ is a useful .net tool that allows to integrate nunit within visual studio.

A quick comparison of the testing frameworks for .net are listed here

A good checklist of unit testing practices to consider for doing Unit testing is listed here.

Conclusion :

It seems that at this time the best way to go about Integration testing is to use Nunit or Xunit whatever one prefers as a testing framework, and adopt either one of the ways listed above to separate your unit tests from integration tests.