Frontend testing of (legacy) websites
1 like258 views
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.
Frontend testing of (legacy) websites
- 1. Fronted tes*ng of (legacy) websites or our approach to e2e testing 3. November 2016
- 3. What it is about
- 4. Our setup - Gherkin, Selenium (php legacy websites) 1
- 5. concepts behind our setup 2
- 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
- 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?
- 18. Test level acceptance black box testing (e2e)
- 19. objectives? test types focus on functional testing acceptance vs regression
- 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