Made for T3DD19 Every developer has made the experience that new changes to a project end up breaking existing code. In a worst-case scenario, these new errors sneak into the production system unnoticed. In order to ensure that your website works, ideally before deploying the code, you should implement automated tests. While most developers are very familiar with functional and unit tests, they often shy away from frontend tests. I want you show you how easy it can be to set up and run browser-based tests with codeception. This way, you can rest assured that your frontend doesn't break without you noticing.

1. Frontend Testing
with Codeception
Christian Keuerleber
... nope, not Unit Tests ;)

2. About me
• Christian „Herbie“ Keuerleber
• Working at punkt.de since2010
• Certified Integrator
• Frontend-guy doing backend stuff
• Likes to make an error only once
Kabarakh – on Twitter, Slack, GitHub...

3. Agenda
• What tools will we be using?
• Monitoring
• Behaviour testing
• Testingin continuous integration
• Questions(and hopefully answers)

4. Tool-Chain
• Php withComposer
• Chrome/Chromium andChromedriver
• For CIwe might need docker

5. (some) Needed Composer Packages
• codeception/codeception
• automatically installeddependencies:
• facebook/webdriver
• behat/gherkin
• guzzlehttp/guzzle
• webmozart/assert

6. A completecomposer.json (formonitoring tests)
{
"name": "punktde/punktde-website-monitoring",
"license": "GPL-3.0+",
"require": {
"codeception/codeception": "^3.0"
},
"autoload": {
"psr-4": {
"PunktDePtwMonitoring": "Classes/"
}
}
}

7. Gherkin?
<?php
classFirstCest
{
public function frontpageWorks(AcceptanceTester $I)
{
$I->amOnPage('/‘);
$I->see('Home‘);
}
}

8. Gherkin!
Feature:As a website user
inorder to beableto seeany content
I want to see the mainpage
Scenario:
Given I am on "/"
ThenIshouldsee"Home"

9. Understandabletests arepartofthe foundation oftrust betweenPOs and developers!

10. Monitoring
Is thewebsite still working?
Did my changes break anything?
Howwill I be notifiedif something breaks?

11. Monitoring
• non-invasive
• runsonproduction
• can beactually run everywhere
• runsas oftenas possible
• (ideally)many small tests
• usesbrowser – liketheusers

12. Behaviour testing
aka

13. Behaviour testing
• Thecodeworks as intended
• Thecodesworks as definedby thePO
• Edgecases andinvalidactions are considered

14. Behaviour testing
• needs a preparedstate (fixture)
• Arrange, Act, Assert
• manipulates database, files andsuch
• runsin its own environment
• shouldrunbeforecodeis even deployed
• tests can bequite largeandcomplex
• usesall technologies youhave – CLI, SQL, Browser,Guzzle, ...

15. Continuous Integration

16. Let's see a live example –and howit is used
... for monitoringat least

17. Buzzword-Bingo!
!!FREE FIELD!!
user-centric
Contexts
Helper classes
Module
Actor
Actor Traits
Features
Scenarios
Scenario Outline
Populator
YAML data files
Guzzle API Tests
Artifacts
Docker
Tablenodes
Params
Database testing
Reusable steps
codeception.yaml
punkt.de GitHub
packages
Environments
JUnit output
Background
Everyone can write
test files

18. (https://twitter.com/michelreimon/status/1156125404014321664)
Questions?

19. Some good-to-knowlinks
• https://codeception.com
• https://cucumber.io/docs/gherkin/reference/
• https://github.com/punktde – searchfor "codeception"
• https://packagist.org/packages/punktde/
• https://github.com/punktDe/codeception-demo