E2E testing, Infrastructure Testing @ ExploreTech Meetup
Freshbooks hosted us.
brief history of testing
- year 2000s – Selenium is used for testing, usually needed lots of work to maintain tests
- year 2010s – SPAs, Frontend and backend split, testing splits, knowledge of a application starts to split between frontend and backend teams.
- year 2017/now – Microservices spread testability out further. How to do e2e tests?
Solutions to E2E
- write E2E test specs in a language readable by everyone like Gherkin, then use or write adapters that adapt the spec to your environment like Cucumber.js and Behat PHP.
- define behaviour of app, not units of app. Descriptions will still make sense.
- Andrew’s example is a spec in Gherkin, with adapters that run the tests against both a REST API and an Angular application running in a browser. Both environments are in separate containers
E2E tests are expensive, test just use them for testing the critical path. Save business logic for unit tests.
- production is never the same as staging. Think about context – does staging have all the same monitoring tools and alerts set up to notify your team of failures? To be sure your backup plans work, you will have to test on on production
Customers aren’t debugging tools
Make inevitable problems come up during business hours when engineers and snacks are available instead of at night
Failure Fridays – someone at pager duty makes a server fail in a controlled way, team sees what happens. This is usually done to 1 just service
“Nuclear Option” testing includes all teams while someone cranks up traffic across all services
Apply scientific method to load testing. Form a hypothesis, run a test, check results
Any surprises from this testing?
Multiplication! Think about spin up times of services that depend on each other in sequence and requests piling up while they wait
HTTP Rate limits at periphery of system don’t help if the event processors at the center of system can’t keep up with back log of requests