Integration testing - seeking your knowledge, advice and links!

Question

Hey guys, I'm after some advice and pointers on integration testing for a web app. Our project has been running for a number of years and it's reasonably complex. We're pretty well covered with unit tests but we're missing a decent set of integration tests. We don't have documented use cases or even a reasonable set of test cases beyond our unit tests. 'Integration testing' today consists of the developer's knowledge of the likely impact of a change and manual, ad-hoc testing of the app. It's really not ideal - we now want to design and automate a solid set of tests to allow us to perform regression testing and increase our confidence in the quality of the app.

We've finally built a platform (based on Selenium) to allow us to quickly author and automate the execution of the tests. The problem now: we don't have any tests, the page is well and truly blank. The system has around 30 classes which interact with each other and influence the UI. For a new user signing up there's about 40 properties that can be set, with each once impacting the experience. Over the user life time they'll generate even more states. Given so many variables and possible states it's a daunting prospect to get started, which is probably why it's been neglected thus far.

The pain of not having a decent set of tests is now becoming destructive. I'm dedicating time to get this problem fixed - I'm after some practical advice on the authoring of the tests. How do you guys approach it? Do you have any links I may find useful? How can I stop my mind running away with the seemingly infinite number of states for a user's data? How can I flush out the edge cases which are failing (and our uses seeming to be finding)?

Help!

Answer 1

If it is the sheer amount of combinations that is holding you back in trying to generate testcases, you should definitly take a look at all-pair testing.

We have used PICT from microsoft as a tool to successfully minimize the amount of testcases while still being reasonable confident to have most cases covered.

the reasoning behind all-pairs testing is this: the simplest bugs in a program are generally triggered by a single input parameter. The next simplest category of bugs consists of those dependent on interactions between pairs of parameters, which can be caught with all-pairs testing.1 Bugs involving interactions between three or more parameters are progressively less common2, whilst at the same time being progressively more expensive to find by exhaustive testing, which has as its limit the exhaustive testing of all possible inputs.