Take your seat, hold on, and see the test infrastructure that every serious tech business needs.
Test cases + mind map, can be seen here: CLICK ME =Manual Task=
This demo test suite, runs a set of Cypress tests on the Stripe Hosted Checkout pages, its purpose is to showcase many test infrastructure best practices. It makes use of:
- Cypress
- TypeScript
- Cypress Testing Library
- cypress-iframe Plugin
- Page Object Model
- Behaviour Driven Development / Cucumber Style Syntax - cypress-cucumber-preprocessor
- Data Driven Testing
- Reusable Functions
- Reusable Test Steps
- CI/CD Integration (Github Actions)
NB: actually, you would not run e2e tests on the stripe checkout hosted by Stripe (you would mock or stub the response), rather if a custom payment flow was chosen implementing form elements directly into our own application with custom styles etc. Custom payment flow integration requires end-to-end testing to make sure everything works as expected and we get a smooth user experience.
- chromeWebSecurity has been disabled (to help with testing stripe iframes), this comes with some consequences (e.g. we might miss some issues that we’d normally catch in a browser with web security enabled).
- viewport is set to mobile view, as this page is dynamic, tests should be run both on mobile and desktop views.
1. Tests written from User-centric view point. The more your tests resemble the way your software is used, the more confidence they can give you.
- Cypress Testing Library - helps you test UI components in a user-centric way, see the core
dom-testing-library
for much more detail. You write tests that mimic the way that the user would use your software.
"You should test your software in the way your users are using it" Kent C. Dodds
- using Page Object Model - a design pattern which externalises web elements/locators, reducing code duplication and improving test case maintenace.
- avoid all e2e Cypress bad practices
3. Reusabability of tests/code. Tests are written with multiple layers, BDD enabling all to understand the purpose/actions of any test/step. This also aids reusability of common test steps.
- using BDD to enable understanding of tests, and easy reusability of test steps, for detail see: cucumber/gherkin-syntaxed specs
- use of Custom Commands typical logic is easily repeatable e.g. a login command
- a single step can be used to drive many test scenarios (each requiring a different set of data), covering all positive and negative eventualities.
CI Intergation - GitHub Actions, repeatable test suite at present runs nightly, automatically or ondemand e.g. by a developers merge.
- Mix of Page Objects and App Actions, where required to set the application state in the desired state immediately, for the purpose of that test.
You will need:
- The following repo cloned: https://github.com/KaterinaUK/Stripe_checkout_payment.git
-
Open terminal in root folder and run
npm install
To start the tests, run the following command in root terminal:
npm run cypress:open
Click on the feature file to run the test.
There are a few tools available to help you debug failed tests on CI:
- The
cypress-failed-log
plugin will display the Cypress commands of any failed test in the CI log. This can help provide context of what hapenned leading up to the test failure. - The result of the Cypress run is saved as an artifact in GitHub, you can find it on the summary page of the Action workflow. Inside the zip file you will find screenshots, videos, and logs of any failed tests.
- If you suspect a test failure might be caused by a graphql api issue you can log every request & response by adding the command
cy.logApiRequests()
to aBefore()
block in your test. Note: this will make the logs very verbose.
Stripe_checkout_payment.-.7.June.2022.mp4
- Slack reporting
- Cypress Dashboard (or similar)
- Code coverage
- More extensive set of edge test cases (not the purpose of this demo)
- Run tests on Desktop & Mobile viewports
- Consider use of docker for test infra in CI
- Load balanced, parralised running of tests in CI
- add mochaawesome reporting