Automated Testing

Some Options

• Puppeteer - https://github.com/puppeteer/puppeteer
• Cucumber - https://cucumber.io/
• Cypress - https://www.cypress.io/
• WebDriver.io - https://webdriver.io/
• Nightwatch - http://nightwatchjs.org/

Considerations

• ES6 support
• documentation/online support
• security/sensitive data
• browser support
• continuous-integration integration
• learning curve
• customizability/reusability
• screenshots

Getting Setup

• Everything is installed through NPM (even the drivers)

Running Tests

Use the Jest CLI to run the puppeteer.

In this example, we are passing in a command-line param which is the PROFILE. Then we call jest with a custom config file and the last is the path to the tests.

Continuous Integration

CircleCI Support

• Requires we run selenium in "online mode"
• CircleCI image must have selenium pre-installed
• LambaTest is an option: https://www.lambdatest.com/
  • Over 2000 selenium browsers running in the cloud
  • Provides access to logs as well as screenshots if you have integrated it 

https://circleci.com/docs/2.0/browser-testing/

CI/CD Strategy

• How often do we want to test?
• What do we want to test?
• Do we want to test on every commit or on every merge into dev/master?
• Run nightly tests to ensure no third party has altered the behaviour of the web app 

Insanity Tests

Sanity Tests

• aka Smoke Screen Tests are a subset of tests we can run to ensure the most crucial and fundamental part of the web app is running as expected (ie: login, logout, main menu is shown and is clickable)
• These tests are meant to be run fairly quickly and give you quick feedback
• If these tests fail then the rest of the tests suites will surely fail

Best Practices

• For repetitive actions and assertions use a functional patterns
• Break into small tests doing 1 or 2 actions, then chain them if needed
• Tackle low hanging fruit first that will give the most business value
• Test on the fastest server first (PROD), then slower QA/Staging servers
• Structure all configurations based on ENV
  • urls
  • timeouts
• For testing breakpoints make tests re-usable with only the window size changing 

• Do not test features that are still in development
• Put yourself in the shoes of QA, what would they test and how?
• Tests should not depend on each other (put things back how you found them)
• Don't over-engineer tests, get them working first, optimize later

Let's Build A Test