CI/CD overview for Puppeteer tests

Learn how to run your Puppeteer test suites on BrowserStack from within your CI/CD pipelines

Introduction

We have already seen how to run your first Puppeteer test on BrowserStack and we have also seen how you can migrate your existing Puppeteer suites to run on BrowserStack.

Running your Puppeteer tests on BrowserStack from within any CI/CD pipeline is pretty straightforward. You just have to ensure that the BrowserStack credentials are passed on the caps variable and that the application server, if hosted privately, can be accessed from BrowserStack servers (learn how to set up Local Testing).

Run Puppeteer tests from CI/CD pipelines

You can visit our documentation pages for the different supported CI/CD integrations as given below. The documentation often mentions Selenium but you can ignore that part and follow the steps to make your Puppeteer tests run using our CI plugins.

Generic steps to follow for triggering Puppeteer tests from any CI/CD tool

Every CI/CD pipeline/tool allows to specify build, test and/or deploy steps as follows:

• The build step should comprise of building your application and making sure that it is hosted in some staging/equivalent environment and ready to be tested.
• The test step is the place where you want to trigger your Puppeteer tests on the BrowserStack infra.
• The deploy step may or may not exist for you depending on your CI/CD setup.

Now, lets see the steps that you need to do in the test step of your build pipeline:

1. You have to ensure that your application under test is hosted on a staging/equivalent server which may or may not be publicly accessible over the Internet.
2. You have to ensure that your internal databases have the test data populated so that the tests can commence.
3. If your application under test (for e.g. https://localhost:3000) is not accessible over the Internet, then you have to set up BrowserStack Local which creates a tunnel connection between your CI build agent/local laptop which has access to the application under test, and the BrowserStack cloud.
4. You can skip step 3 if your application under test (for e.g. https://staging.example.com) is accessible through the public Internet.
5. As part of the test stage, you have to trigger your Puppeteer tests using node or any other wrapper framework / test runner that you might be using for e.g. Jest or CodeceptJS. You can also write a custom bash script which takes care of multi-threading for parallelization and invokes the tests one after the other / in parallel.
6. As mentioned in step 5, if you are testing against privately hosted website, then your Puppeteer scripts should contain browserstack.local set to true in caps. See Local testing documentation.
7. As mentioned in step 5, your Puppeteer scripts should use the puppeteer.connect method to get the browser instance from BrowserStack, instead of using the puppeteer.launch which launches the browser in the same machine. See documentation for migrating your test suites