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)
"puppeteer": "2.0.0",Running Tests
PROFILE=local jest -c jest.puppeteer.config.js automation/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Ā
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