Testing ASP.NET Web Applications

4.1. Integration Tests versus Unit Tests

As integration tests cross boundaries they are more fragile than unit tests. This is one of the reasons why you should always store your integration tests in a separate assembly from your unit tests. The aim for your unit tests is to run consistently and to always be green. If your unit tests are not green then you have broken something. Integration tests are different. They might fail for other reasons outside of your control. For example, if the database is not in the expected state or even accessible, then the test will fail. This is why they are fragile and why you want to separate the two types — so that you can keep the warm feeling of seeing the green bar for as long as possible. By dividing, you have more chance of always seeing a totally green bar. This is important, and it comes back to the broken window syndrome mentioned in Chapter 2. If you always see some tests are broken, then you'll become used to it and let things slide. If you have your unit and integration tests together, you'll be used to seeing red appear every now and again. As a result, you won't notice when unit tests have failed. As discussed in the previous chapter, the name of your project would be ProjectName.Tests.Integration.

The other reason is for speed, because integration tests are generally slower than unit tests. You'll generally be running your unit tests more often because they contain all your logic, so you'll want these tests to run much faster. To ...