Building coverage as you grow with Rainforest

After you've become an awesome Rainforest customer, there will be an evolution in your usage that will help you get the most out of Rainforest. Let's go through the playbook.

This guide is sequential—the order matters. If you have questions, please get in touch!

1. Testing against production

To start with, you should probably be testing against production.


Testing against production is the easiest and fastest way to get some results, because you don't have to create a staging environment. In addition, testing against production can be useful for monitoring purposes if your application changes outside of code deploys.


Simply point your Rainforest tests to your production site in the Site settings.


  • Publicly-accessible website

2. Testing against staging

Next, you should test against staging.


Testing against staging is crucial because it means you and your team can catch and fix bugs before reach your customers. It's hard to overstate the importance of this—a bug caught in staging is far cheaper than one that makes it to production to fix.


Add your staging environment to your sites, then configure your tests to run against the staging environment. Then once you're ready to test, run your tests in the standard way.

If you're simply replacing production with staging, you can just update the existing site.


  • Staging server
  • Data on staging server so that your testers can use the application like in production
  • Some way for testers to access it (can be authentication of various kinds)

3. Testing releases automatically

Use a Continuous Integration server to automatically run your Rainforest tests against important releases.


Most sites are updated by releases. By running your releases through Rainforest you vastly decrease the chance of shipping bugs, since Rainforest catches them before they go to Production. That means your customers stay unaffected.

Using CI is recommended because it means that your tests and build process are kicked off automatically, which vastly reduces the risk of human error and makes it impossible to forget.


It's pretty easy to run your Rainforest suite from the command line using our Command Line Interface (CLI). There's a quick guide on how to use it in our documentation. Most of our customers choose to use a combination of our CLI client and a cloud-hosted CI provider (we love and use CircleCI, but there are a bunch of great ones) for maximum win.

The only hard part is figuring out which of your builds should be run against Rainforest. We run all builds that are triggered by a release (for us that's the Develop -> Master branch merge), but you could run all builds, or all builds with a certain tag, or all builds triggered by a certain branch. Get in touch if you have a custom requirement that you don't know how to setup—chances are we've already seen it.


  • Continuous Integration process
  • Rainforest-CLI
Did this answer your question?