When you are running an integration test of any sort, one of the things you need to deal with is configuring the other component(s) you are interacting with; either for step 0 or later. There are a couple ways that you can deal with this, each with their pros and cons. And unsurprisingly, there is a order I would approach these.

The easiest thing to do is create a script that executes all your setup in the other system(s). This is great since it is actually running through the end user process of creating the data in the system. Good or bad, it is ‘real’. But let’s face it, Selenium tests are not really zippy to begin with and what if you have a half dozen of these scripts to run? Well, your feedback loop is getting longer and longer. I’m not sure how much parallelization of tests will even solve the setup problem. This slowness of execution is offset though by the speed of creation (when prototyping with Se-IDE).

What if you could have the benefit of using properly generated data but without the speed penalty of using a browser? Well, if you are using something like Rails you can make use of its RESTful dna. Properly constructed, creating data becomes as easy as POSTing a properly formatted string to the server and voila!, you have data. Yes, the user isn’t creating it directly, but if the app is properly constructed then all the same business rules will be triggered as well.

But using a RESTful interface still means a network hit as well as being at the mercy of another system’s state. You can get rid of that by appropriate use of a Test Double. In this case, what you likely want is a Stub. A Stub returns canned data in response to certain criteria in the application. This breaks the very notion of ‘integration’ testing by removing the integration, but lets you quickly test the ‘as long as the other end continues to send information in the format I expect’ scenario. And that is a pretty important one. You have to remember to remove the stub every so often to make sure that it is still be getting the same data though.

You could in theory jump straight to the Stub step if you choose, but I think there is value to going through all the steps. First, you verify what is being sent by the app. Next you verify that the business logic is not in the presentation layer by replacing the browser by an API and then you supercharge the script execution.

And all the while you are learning about the application you are testing — and learning is kinda the point of testing.