One of the underlying principles of designing your CI builds is that the value of information about a build failure diminishes rapidly with time. In other words, the longer the news of a build failure takes to get to you, the less it is worth, and the harder it is to fix.
Indeed, if your functional or integration tests are taking several hours to run, chances are they won’t be run for every change. They are more likely to be scheduled as a nightly build. The problem with this is that a lot can happen in twenty-four hours, and, if the nightly build fails, it will be difficult to figure out which of the many changes committed to version control during the day was responsible. This is a serious issue, and penalizes your CI server’s ability to provide the fast feedback that makes it useful.
Of course some builds are slow, by their very nature. Performance or load tests fall into this category, as do some more heavyweight code quality metrics builds for large projects. However, integration and functional tests most definitely do not fall into this category. You should do all you can to make these tests as fast as possible. Under ten minutes is probably acceptable for a full integration/functional test suite. Two hours is not.
So, if you find yourself needing to speed up your tests, here are a few strategies that might help, in approximate order of difficulty.
Sometimes the easiest way to speed up your builds is to throw more hardware into the ...