The document discusses the challenges and motivations behind end-to-end (e2e) testing for legacy websites, particularly within the context of a central European web hosting company. It emphasizes the importance of clear definitions and understanding user and system requirements while proposing a structured testing methodology using frameworks like Gherkin, Selenium, and BDD. The author shares practical steps for setting up a testing environment and offers insights into creating effective tests while managing legacy systems.

1. Fronted tes*ng of
(legacy) websites
or our approach to e2e testing
3. November 2016

2. Scope
What? Who? Why?

3. What it is about

4. Our setup
- Gherkin, Selenium (php
legacy websites)
1

5. concepts behind our setup
2

6. getting there effortlessly
3

7. how do we approach the
problem

8. About me
Software Engineer at
a central european Webhosting company
part-time SE student at Oxford University

9. What’s the
problem?
Motivation

10. Our architecture
a lot of legacy
new features being added constantly

11. Typical scenario
vague feature requests
not sure about how some feature works
does it even work?
you broke my feature!!!

12. Theory
Rationale

14. Not really
we need to agree on definitions
in order to reason about our choices
what are we trying to achieve?

15. V model
Need, Want,
Law
User
Requirement
System
Requirement
Architecture
Detailed design
Implementa*on
Opera*onal
system
Acceptance test
execu*on
System test
execu*on
Integra*on test
execu*on
Component
test execu*on

16. Test levels
Need, Want,
Law
User
Requirement
System
Requirement
Architecture
Detailed design
Implementa*on
Opera*onal
system
Acceptance test
execu*on
System test
execu*on
Integra*on test
execu*on
Component
test execu*on

17. Front-end testing
Need, Want,
Law
System
Requirement
Architecture
Detailed design
Implementa*on
Opera*onal
system
System test
execu*on
Integra*on test
execu*on
Component
test execu*on
User
Requirement
Acceptance test
execu*on

18. Test level
acceptance black box testing (e2e)

19. objectives?
test types
focus on functional testing
acceptance vs regression

20. Gherking,
Framework & BDD
huh?

21. “Acceptance testing doesn't
actually handle
conversations, and usually
works from an assumption
that the tests you're
writing are the right tests”

22. BDD gives us
conventions
the tool (Behat/Cucumber)
is to help with acceptance aspects
not the functional aspects
in “theory” allows customer interaction

23. BDD mantra
For who? What? How?

24. In order to buy a hosting
package
as a potential customer
I need to put Hosting package
to cart
Scenario: Adding a specific
The Hosting package to cart
Given…

25. Enough of theory
or 0 to 100 real quick

26. Choose testing framework
in the language of your
website
1

27. Setup your testing website
in env you can control
(any docker fans?)
2

28. Use real browsers with
javascript (if UI requires it)
3

29. Don’t reinvent the wheel!
4

30. Selenium in
seconds
docker FTW
https://github.com/SeleniumHQ/docker-selenium
we use https://github.com/elgalu/docker-selenium

31. Setup testing
framework
Behat / Cucumber / whatever language you use
Reuse as much DSL as you can
“I am on”, “I press button xxx”, etc..
Write your first useful feature

32. Caveats
controlling the state
how to jump straight to “Given” state?

33. Given I have following
products in cart:
– The Hosting
– .hu domain
– .eu domain

34. Put that state
under control
Use framework in your language so you can infiltrate
“behind the scenes”

35. Session
Fixed session name
Instantiate app in background
Manipulate your known session

36. Next steps
where to go from here

37. Profit!
Fix wikipedia (acceptance testing annoyance)
Beer!

38. Thank you
you are awesome
webonic.hu
michaelkubovic.com
fb.me/michael.kubovic