icon sc-linkedin logo of codepen-icon logo of github-icon youtube play button

notes by Adam Sullovey

web & mobile application developer
practicing in Toronto, ON

E2E testing, Infrastructure Testing @ ExploreTech Meetup

E2E testing, Infrastructure Testing @ ExploreTech Meetup

Freshbooks hosted us.

Andrew Kirkpatrick from Unata talked about behaviour driven development & testing.

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.


Renee Lung from pagerduty talked about infrastructure testing

Renee presenting

why

  • 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

how

  • 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

https://www.meetup.com/ExploreTech-Toronto/events/242181690/

comments powered by Disqus