Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Behaviour testing for single-page applications and API’s

462 views

Published on

Talk given at ExploreTech Toronto in August 2017 by Andrew Kirkpatrick on behaviour testing for single-page applications and API’s using Gherkin, Behat and containerization

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Behaviour testing for single-page applications and API’s

  1. 1. BEHAVIOURTESTING FOR SINGLE-PAGE APPLICATIONS AND API’S Andrew Kirkpatrick, ExploreTechTO August 2017
  2. 2. BEHAVIOURTESTING FOR SINGLE-PAGE APPLICATIONS AND API’S
  3. 3. WHO AM I? • Long-time PHP developer • Spent most of my career in London, England • Focus on BDD and DDD • This talk is a combination of various things I’ve learnt or been taught about testing
  4. 4. WHAT WE’LL COVER • How testing the web has evolved • Divide of front-end and back-end codebases and how this affects end-to-end testing • Why Behaviour Driven Development? • How you can implement this on your codebases
  5. 5. TESTINGTHE WEB (MID 2000S) • Static HTML pages • Test that certain content appears in the DOM where you’d expect • Functional testing is relatively easy (call a URI, check the HTML)
  6. 6. TESTINGTHE WEB (LATE 2000S) • Web 2.0, dynamic changes to the DOM • Tools such as Selenium use real browsers to test JS DOM manipulation • Front-end still rendered by the back-end
  7. 7. SELENIUM • Remote control web browsers, create repeatable tests • Tests often created separately from development • Often run manually, originally difficult to run during build process
  8. 8. TESTINGTHE WEB (EARLY 2010S) • Single-page JavaScript applications • Front-end often becomes separated from the back- end • Communication moves from XHR calls to dedicated REST API(s)
  9. 9. TESTINGTHE WEB (PRESENT DAY) • Multiple applications running on multiple servers/containers • Popularity of (Micro) Service-Oriented Architecture • Testing SOA easier in isolation, but more complex end-to-end
  10. 10. WHY DIDTHEY BREAK IT AGAIN? • Assumptions as to what constitutes “backwards- compatible” • 100% code coverage does not mean they will work together • Need an easy and automated way to test end-to-end
  11. 11. TEST SUITE COMPLEXITY • Front-end and back-end test suites become very specialised, focus on unit and integration testing • Functional (end-to-end) testing still often run manually, could testing the critical path be automated? • How to write tests that business stakeholders can understand?
  12. 12. TYPICAL UNITTESTS Would any of your stakeholders understand what feature this proves is working?
  13. 13. MORE UNITTESTS Multiple languages often equals more tests that are difficult to read for those not familiar
  14. 14. BEHAVIOUR DRIVEN DEVELOPMENT “I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.” Dan North 2006
  15. 15. WHAT IS BEHAVIOUR DRIVEN DEVELOPMENT? “The use of BDD requires no particular tools or programming languages, and is primarily a conceptual approach; to make it a purely technical practice or one that hinges on specific tooling would be to miss the point altogether” Agile Alliance
  16. 16. GHERKIN Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented.
  17. 17. WHY IS BDD IMPORTANT? • Ubiquitous language to describe business concepts (same terminology) • Use BDD scenarios to control test automation (e.g. Selenium) • Feature and the automation to test it should be abstracted
  18. 18. SAME SCENARIOS, DIFFERENT CONTEXTS • Features are not front-end or back-end specific • Different automation to test each part that powers the feature • How to control both HTML/JS and REST API testing?
  19. 19. BEHAT FOR PHP • “Behat is the official Cucumber implementation for PHP” • “Behat shares a lot with Cucumber and the philosophies are one and the same” • Test runner for Gherkin .feature files
  20. 20. DEMO • Repository with 3 containers (front-end, back-end and test runner) • Run the BDD tests from one container against the other 2 • What if the tests fail?
  21. 21. EXAMPLE CI PIPELINE Trigger end-to-end behavioural tests after successful front- end or back-end builds
  22. 22. BDD FRAMEWORKS • Behat for PHP (behat.org) • Cucumber-Rails for Ruby
 (cucumber.io/docs/reference/rails) • Behave for Python (behave.readthedocs.io) • JBehave for Java (jbehave.org) • SpecFlow for .NET (specflow.org)
  23. 23. CAVEATS • This is only one of many, many ways to solve the problems of complex multi-application testing • This is not a replacement for thorough unit testing nor integration testing • End-to-end testing is expensive (time) so only test the critical path
  24. 24. LINKS • Test automation pyramid (www.mountaingoatsoftware.com/blog/the- forgotten-layer-of-the-test-automation-pyramid) • Gherkin language (github.com/cucumber/cucumber/wiki/Gherkin) • Where you should use BDD (cucumber.io/blog/2016/07/20/ where_should_you_use_bdd) • Configuring suites with different contexts (behat.org/en/latest/user_guide/ configuration/suites.html) • Using BDD to test API’s (speakerdeck.com/caseysoftware/is-your-api- misbehaving-workshop)
  25. 25. SUMMARY • Business-Readable scenarios of the features you want to test • Testing via different contexts including end-to-end • Can be created and maintained by any team
  26. 26. SLIDES AND CODE • github.com/magickatt/ MultiContextBDDTalk • hub.docker.com/r/magickatt/ behat-mink • www.slideshare.net/magickatt/ behaviour-testing-for- singlepage-applications-and-apis • twitter.com/magickatt • Any questions?

×