1. BEHAVIOURTESTING FOR SINGLE-PAGE
APPLICATIONS AND API’S
Andrew Kirkpatrick, ExploreTechTO August 2017

2. BEHAVIOURTESTING FOR
SINGLE-PAGE APPLICATIONS
AND API’S

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. 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. 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. 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. 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. 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. 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. 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. 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. TYPICAL UNITTESTS
Would any of your stakeholders understand what feature
this proves is working?

13. MORE UNITTESTS
Multiple languages often equals more tests that are difficult
to read for those not familiar

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. 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. GHERKIN
Business Readable, Domain Specific Language that lets you describe
software’s behaviour without detailing how that behaviour is implemented.

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. 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. 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. 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?

27. EXAMPLE CI PIPELINE
Trigger end-to-end behavioural tests after successful front-
end or back-end builds

28. 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)

29. 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

30. 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)

31. 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

32. 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?