{"id":6713,"date":"2026-06-08T11:40:14","date_gmt":"2026-06-08T09:40:14","guid":{"rendered":"https:\/\/www.clickstorm.de\/blog\/?p=6713"},"modified":"2026-06-16T11:04:51","modified_gmt":"2026-06-16T09:04:51","slug":"automatisierte-tests-codeception","status":"publish","type":"post","link":"https:\/\/www.clickstorm.de\/blog\/automatisierte-tests-codeception\/","title":{"rendered":"Automatisierte Tests mit Codeception: So sichern wir Webprojekte ab"},"content":{"rendered":"

Codeception hilft uns dabei, zentrale Funktionen einer Website nach Updates, Relaunches oder Deployments automatisiert zu testen.<\/p>\n

Nach einem Update, Relaunch oder Deployment stellt sich oft dieselbe Frage: Funktioniert noch alles? L\u00e4sst sich das Kontaktformular absenden? \u00d6ffnet sich der Login? Erscheint der Cookie-Banner? Genau an dieser Stelle helfen automatisierte Tests. Sie pr\u00fcfen wiederkehrende Abl\u00e4ufe nicht manuell, sondern reproduzierbar und zuverl\u00e4ssig. In vielen unserer Projekte setzen wir daf\u00fcr Codeception ein \u2013 vor allem f\u00fcr automatisierte Browser-Tests.<\/p>\n

In diesem Beitrag zeigen wir dir, welche Testarten es gibt, warum Akzeptanztests f\u00fcr Webprojekte besonders wertvoll sind, wie Codeception funktioniert und welche Erfahrungen wir bei clickstorm damit gemacht haben.<\/p>\n

Welche Testarten gibt es?<\/h2>\n

Automatisierte Tests k\u00f6nnen auf unterschiedlichen Ebenen ansetzen. Jede Testart verfolgt ein anderes Ziel und hat ihre eigene Berechtigung. TYPO3 unterscheidet in der offiziellen Dokumentation<\/a> ebenfalls zwischen verschiedenen Testebenen wie Unit-, Functional- und Acceptance-Tests.<\/p>\n

Unit-Tests<\/h3>\n

Unit-Tests pr\u00fcfen einzelne, m\u00f6glichst kleine Code-Einheiten isoliert. Das k\u00f6nnen Funktionen, Methoden oder Klassen sein. Sie sind schnell, gut automatisierbar und eignen sich besonders f\u00fcr Logik, Berechnungen oder klar abgegrenzte Gesch\u00e4ftsregeln.<\/p>\n

Ein Unit-Test beantwortet zum Beispiel die Frage:<\/p>\n

Liefert diese Methode bei einer bestimmten Eingabe das erwartete Ergebnis?<\/p><\/blockquote>\n

Gerade in TYPO3-, Symfony- oder Shopware-Projekten sind Unit-Tests hilfreich, wenn individuelle Logik sauber abgesichert werden soll.<\/p>\n

Funktionale Tests<\/h3>\n

Funktionale Tests pr\u00fcfen bestimmte Funktionen innerhalb einer Anwendung. Sie liegen h\u00e4ufig zwischen Unit-Tests und Akzeptanztests. Im TYPO3-Umfeld werden funktionale Tests zum Beispiel genutzt, um Verhalten mit einer realistischeren TYPO3-Umgebung zu testen.<\/p>\n

Typische Fragen sind:<\/p>\n

Wird ein Datensatz korrekt verarbeitet?
\nWird eine bestimmte Funktion innerhalb der Anwendung wie erwartet ausgef\u00fchrt?
\nFunktioniert ein Plugin oder eine Extension mit der vorhandenen Konfiguration?<\/p><\/blockquote>\n

Akzeptanztests<\/h3>\n

Akzeptanztests pr\u00fcfen komplette Abl\u00e4ufe aus Sicht der Nutzerinnen und Nutzer. Sie simulieren typische Wege durch eine Website oder Webanwendung: Seite \u00f6ffnen, Button klicken, Formular ausf\u00fcllen, absenden und Ergebnis pr\u00fcfen.<\/p>\n

TYPO3 beschreibt Acceptance Testing als das Steuern eines Browsers, um durch ein Frontend oder Backend-Szenario zu klicken. Genau in diesem Bereich setzen wir Codeception in vielen Projekten ein.<\/p>\n

Warum Akzeptanztests besonders wertvoll sind<\/h3>\n

Akzeptanztests sind besonders nah an der tats\u00e4chlichen Nutzung einer Website. Sie pr\u00fcfen nicht nur, ob einzelne Code-Bausteine funktionieren, sondern ob ein kompletter Ablauf erfolgreich ist.<\/p>\n

Ein Beispiel: Ein Kontaktformular besteht aus vielen einzelnen Teilen. Es gibt ein Template, Formularfelder, Validierung, Spam-Schutz, Versandlogik, Weiterleitungen und Erfolgsmeldungen. Ein Akzeptanztest pr\u00fcft nicht jedes Detail isoliert, sondern den gesamten Weg:<\/p>\n

    \n
  1. Kontaktseite \u00f6ffnen<\/li>\n
  2. Formularfelder ausf\u00fcllen<\/li>\n
  3. Formular absenden<\/li>\n
  4. Erfolgsmeldung pr\u00fcfen<\/li>\n<\/ol>\n

    Das ist besonders wertvoll bei wiederkehrenden manuellen Tests. Vor einem Deployment muss nicht jedes Formular, jeder Login oder jeder Anfrageprozess per Hand durchgeklickt werden. Stattdessen \u00fcbernehmen automatisierte Tests diese Aufgabe.<\/p>\n

    Nat\u00fcrlich ersetzen solche Tests keine gute Entwicklung, kein Code-Review und keine fachliche Abnahme. Aber sie schaffen zus\u00e4tzliche Sicherheit und helfen, Fehler fr\u00fchzeitig zu erkennen.<\/p>\n

    Was ist Codeception?<\/h2>\n

    Codeception ist ein Testing-Framework f\u00fcr PHP. Es unterst\u00fctzt verschiedene Testarten und legt einen starken Fokus auf lesbare, nutzernahe Tests. Die offizielle Codeception-Seite beschreibt das Framework als L\u00f6sung f\u00fcr das Testen von PHP-Webanwendungen mit Modulen f\u00fcr unter anderem Browser-Testing und nutzerzentrierte Tests.<\/p>\n

    F\u00fcr Browser-Tests kann Codeception das WebDriver-Modul nutzen. Damit laufen Tests in echten Browsern \u00fcber das W3C-WebDriver-Protokoll, zum Beispiel mit Chrome oder Firefox.<\/p>\n

    F\u00fcr uns ist besonders wichtig: Die Tests werden in PHP geschrieben. Als Agentur mit Schwerpunkten in TYPO3, WordPress, Shopware, Symfony und individuellen PHP-Projekten passt das sehr gut zu unserem Alltag. Wir bleiben in einer Sprache und einem \u00d6kosystem, das unser Team ohnehin t\u00e4glich nutzt.<\/p>\n

    Wie funktionieren Browser-Tests mit Codeception?<\/h3>\n

    Ein Browser-Test mit Codeception beschreibt einen Ablauf so, wie ihn auch ein Mensch im Browser durchf\u00fchren w\u00fcrde.<\/p>\n

    Zum Beispiel:<\/p>\n

    $I->amOnPage('\/kontakt');\r\n$I->fillField('Name', 'Max Mustermann');\r\n$I->fillField('E-Mail', 'max@example.de');\r\n$I->fillField('Nachricht', 'Das ist eine Testnachricht.');\r\n$I->click('Absenden');\r\n$I->see('Vielen Dank');<\/pre>\n
    Der Test liest sich fast wie eine kleine Anleitung:<\/p>\n
      \n
    1. Gehe auf die Kontaktseite.<\/li>\n
    2. F\u00fclle die Felder aus.<\/li>\n
    3. Klicke auf Absenden.<\/li>\n
    4. Pr\u00fcfe, ob die Erfolgsmeldung erscheint.<\/li>\n<\/ol>\n
      Das macht Codeception auch f\u00fcr Teams gut verst\u00e4ndlich, die nicht jeden Tag komplexe Testframeworks konfigurieren m\u00f6chten.<\/p>\n
      Codeception installieren<\/h2>\n
      Codeception kann in einem PHP-Projekt \u00fcber Composer installiert werden. F\u00fcr Browser-Tests werden neben Codeception selbst auch passende Module ben\u00f6tigt.<\/p>\n
      composer require codeception\/codeception \\\r\ncodeception\/module-asserts \\\r\ncodeception\/module-phpbrowser \\\r\ncodeception\/module-webdriver \\\r\n--dev<\/pre>\n
      Anschlie\u00dfend wird Codeception initialisiert:<\/p>\n
      vendor\/bin\/codecept bootstrap<\/pre>\n
      Dabei erzeugt Codeception die grundlegende Konfiguration und die Teststruktur im Projekt.<\/p>\n
      Falls Autoloading f\u00fcr Tests oder projektspezifische Namespaces ben\u00f6tigt wird, kann die composer.json entsprechend erweitert werden:<\/p>\n
      {\r\n  \"autoload-dev\": {\r\n    \"psr-4\": {\r\n      \"Tests\\\\\": \"tests\"\r\n    }\r\n  }\r\n}<\/pre>\n
      Danach sollte der Autoloader neu erzeugt werden:<\/p>\n
      composer dump-autoload -o<\/pre>\n
      Selenium starten<\/h3>\n
      F\u00fcr echte Browser-Tests ben\u00f6tigt Codeception einen WebDriver. H\u00e4ufig wird daf\u00fcr Selenium genutzt.<\/p>\n
      Eine lokale M\u00f6glichkeit ist selenium-standalone \u00fcber npm:<\/p>\n
      npm install selenium-standalone -g\r\nselenium-standalone install\r\nselenium-standalone start<\/pre>\n
      Wenn der ChromeDriver nicht mehr zur installierten Chrome-Version passt, kann er aktualisiert werden:<\/p>\n
      selenium-standalone install --drivers.chrome.version=latest<\/pre>\n
      Das ist eine typische Fehlerquelle in der Praxis. Wenn Tests pl\u00f6tzlich keine Verbindung mehr zum Browser herstellen k\u00f6nnen oder Chrome nicht korrekt startet, lohnt sich oft zuerst ein Blick auf die Versionen von Chrome und ChromeDriver.<\/p>\n
      Codeception mit DDEV und Selenium nutzen<\/h3>\n
      In DDEV-Projekten bietet sich das Add-on ddev-selenium-standalone-chrome an. Es stellt Selenium mit Chrome als Service innerhalb der DDEV-Umgebung bereit. Das Add-on ist laut Projektbeschreibung f\u00fcr browserbasierte Tests mit Selenium in DDEV gedacht und kann grunds\u00e4tzlich mit verschiedenen Projekttypen genutzt werden.<\/p>\n
      Die Installation erfolgt zum Beispiel mit:<\/p>\n
      ddev add-on get ddev\/ddev-selenium-standalone-chrome\r\nddev restart<\/pre>\n
      Anschlie\u00dfend muss Codeception so konfiguriert werden, dass es den Selenium-Service innerhalb von DDEV nutzt.<\/p>\n
      Ein Beispiel f\u00fcr eine codeception.yml oder eine Suite-Konfiguration:<\/p>\n
      actor: AcceptanceTester\r\nmodules:\r\n  enabled:\r\n    - WebDriver:\r\n        url: https:\/\/myproject.ddev.site\r\n        host: selenium-chrome\r\n        browser: chrome\r\n        capabilities:\r\n          goog:chromeOptions:\r\n            args:\r\n              - '--ignore-certificate-errors'\r\n              - '--disable-dev-shm-usage'<\/pre>\n
      Die beiden Chrome-Argumente sind in DDEV-Projekten besonders praktisch:<\/p>\n
      --ignore-certificate-errors<\/pre>\n
      Damit akzeptiert Chrome selbstsignierte DDEV-Zertifikate.<\/p>\n
      --disable-dev-shm-usage<\/pre>\n
      Das kann Probleme mit gemeinsam genutztem Speicher in Container-Umgebungen vermeiden.<\/p>\n
      Lokale Projekt-URLs sollten nicht fest in Git landen. Deshalb kann die URL auch \u00fcber eine Umgebungsvariable gesetzt werden, zum Beispiel:<\/p>\n
      url: '%CODECEPTION_URL%'<\/pre>\n
      Beispiel: Ein Formular automatisch testen<\/h3>\n
      Ein typischer Akzeptanztest pr\u00fcft, ob ein Formular erreichbar ist, sich ausf\u00fcllen l\u00e4sst und nach dem Absenden die erwartete R\u00fcckmeldung erscheint.<\/p>\n
      <?php\r\n\r\nclass ContactFormCest\r\n{\r\n    public static string $URL_CONTACT = '\/kontakt';\r\n    public static string $CSS_SUCCESS_MESSAGE = '.success-message';\r\n\r\n    public function contactFormCanBeSubmitted(AcceptanceTester $I): void\r\n    {\r\n        $I->wantTo('submit the contact form');\r\n\r\n        $I->amOnPage(static::$URL_CONTACT);\r\n        $I->see('Kontakt');\r\n\r\n        $I->fillField('Name', 'Max Mustermann');\r\n        $I->fillField('E-Mail', 'max@example.de');\r\n        $I->fillField('Nachricht', 'Das ist eine Testnachricht.');\r\n\r\n        $I->click('Absenden');\r\n\r\n        $I->waitForElementVisible(static::$CSS_SUCCESS_MESSAGE, 10);\r\n        $I->see('Vielen Dank');\r\n    }\r\n}<\/pre>\n
      Dieser Test ist bewusst einfach gehalten. In echten Projekten kommen h\u00e4ufig weitere Aspekte hinzu: Pflichtfelder, Validierungsfehler, Spam-Schutz, Weiterleitungen, mehrsprachige Formulare oder unterschiedliche Formularvarianten.<\/p>\n
      Codeception-Tests ausf\u00fchren<\/h2>\n
      Codeception-Tests k\u00f6nnen direkt \u00fcber die Konsole gestartet werden:<\/p>\n
      vendor\/bin\/codecept run --steps --html<\/pre>\n
      Mit --steps<\/code> werden die einzelnen Schritte ausgegeben. Mit --html<\/code> wird ein HTML-Report erzeugt. Das ist besonders hilfreich, wenn Tests in CI\/CD-Prozessen laufen oder wenn ein Fehler sp\u00e4ter nachvollzogen werden soll.<\/p>\n
      Ein einzelner Test kann so gestartet werden:<\/p>\n
      vendor\/bin\/codecept run tests\/Acceptance\/ContactFormCest.php --steps --html<\/pre>\n
      Nur fehlgeschlagene Tests k\u00f6nnen erneut ausgef\u00fchrt werden:<\/p>\n
      vendor\/bin\/codecept run --steps --html --group failed<\/pre>\n
      Wenn veraltete Testreferenzen Probleme machen, hilft manchmal ein Clean-Lauf:<\/p>\n
      vendor\/bin\/codecept clean<\/pre>\n
      Codeception in PhpStorm starten<\/h3>\n
      Codeception-Tests lassen sich nicht nur \u00fcber die Konsole ausf\u00fchren, sondern auch direkt in PhpStorm. Das ist besonders praktisch, wenn du einzelne Tests w\u00e4hrend der Entwicklung schnell starten m\u00f6chtest.<\/p>\n
      Damit PhpStorm Codeception korrekt ausf\u00fchren kann, muss zuerst der passende PHP-Interpreter eingerichtet sein.<\/p>\n
      \"PhpStorm<\/p>\n
      Auch der Selenium-Server muss gestartet sein (siehe oben). Anschlie\u00dfend sind folgende Schritte auszuf\u00fchren:<\/p>\n
        \n
      1. Rechtsklick auf den Test-Ordner<\/li>\n
      2. „Run“ w\u00e4hlen<\/li>\n
      3. Klick auf Codeception.<\/li>\n<\/ol>\n
        \"Codeception<\/p>\n
        Jetzt sollte sich der Chrome-Browser \u00f6ffnen. Unterhalb in PhpStorm \u00f6ffnet sich ebenfalls die Run-Ansicht, wo der Fortschritt der Tests sowie fehlgeschlagene Tests zu sehen sind. Im Anschluss lassen sich auch nur die fehlgeschlagenen wiederholen.<\/p>\n
        \"Codeception<\/p>\n
        Best Practices aus unserer Praxis<\/h2>\n
        Mit der Zeit haben sich bei uns einige Regeln bew\u00e4hrt, die Codeception-Tests stabiler und wartbarer machen.<\/p>\n
        Selektoren bewusst definieren<\/h3>\n
        Selektoren, URLs und erwartete Werte sollten nicht \u00fcberall im Test verstreut stehen. Wir legen sie lieber als Variablen an. So bleiben Tests lesbarer und \u00c4nderungen lassen sich schneller durchf\u00fchren.<\/p>\n
        public static string $URL_TO_TEST = '\/';\r\npublic static string $CSS_LINK_DETAIL = '.test-link-detail';\r\npublic static string $CODE_IN_DETAIL_VIEW = '<h2>';\r\npublic static int $NUMBER_OF_LIST_ITEMS = 6;<\/pre>\n
        Als Namenskonvention nutzen wir sprechende Pr\u00e4fixe:<\/p>\n
        CSS_        f\u00fcr CSS-Selektoren\r\nURL_        f\u00fcr URLs\r\nCODE_       f\u00fcr erwarteten HTML-Code\r\nNUMBER_OF_  f\u00fcr erwartete Anzahlen<\/pre>\n
        Wenn CSS-Klassen nur f\u00fcr Tests eingef\u00fchrt werden, bietet sich ein eindeutiges Pr\u00e4fix an, zum Beispiel:<\/p>\n
        .test-link-detail<\/pre>\n
        So ist sofort sichtbar, dass diese Klasse nicht f\u00fcr Styling oder JavaScript gedacht ist, sondern f\u00fcr automatisierte Tests.<\/p>\n
        Robuste XPath-Selektoren verwenden<\/h3>\n
        Manchmal reicht ein einfacher CSS-Selektor nicht aus. Wenn ein Element anhand einer Klasse und eines konkreten Textes gefunden werden soll, kann XPath helfen:<\/p>\n
        public static $XPATH_ITEM = '\/\/li[contains(concat(\" \", normalize-space(@class), \" \"), \" mycssclass \")][text()=\"mytext\"]';<\/pre>\n
        Solche Selektoren sollten sparsam eingesetzt werden, k\u00f6nnen aber bei komplexeren Templates hilfreich sein.<\/p>\n
        Nicht fest warten, sondern gezielt warten<\/h3>\n
        Eine der wichtigsten Regeln: Tests sollten m\u00f6glichst nicht einfach eine feste Anzahl Sekunden warten.<\/p>\n
        Stattdessen ist es besser, auf einen konkreten Zustand zu warten:<\/p>\n
        $I->waitForElementVisible(static::$CSS_AJAX_IS_LOADING, $timeout);\r\n$I->waitForElementNotVisible(static::$CSS_AJAX_IS_LOADING, $timeout);<\/pre>\n
        Oder darauf, dass das Dokument fertig geladen ist:<\/p>\n
        $I->waitForJS('return document.readyState == \"complete\"');<\/pre>\n
        Codeception unterst\u00fctzt verschiedene Wait-Methoden im WebDriver-Modul; au\u00dferdem beschreibt die Dokumentation mit \u201eSmartWait\u201c einen Mechanismus, bei dem Codeception beim Suchen bestimmter Elemente kurz warten kann, ohne alle Testschritte pauschal auszubremsen.<\/p>\n
        In der Praxis ist das wichtig, weil viele Websites heute mit Ajax, Animationen, Consent-Bannern oder nachgeladenen Inhalten arbeiten. Ein Test, der zu fr\u00fch klickt oder pr\u00fcft, kann fehlschlagen, obwohl die Website korrekt funktioniert.<\/p>\n
        Optionale Elemente mit tryTo pr\u00fcfen<\/h3>\n
        Nicht jedes Element ist immer sichtbar. Ein Sprachmen\u00fc kann tempor\u00e4r ausgeblendet sein. Ein Veranstaltungskalender kann leer sein. Ein Hinweis kann nur unter bestimmten Bedingungen erscheinen.<\/p>\n
        F\u00fcr solche F\u00e4lle k\u00f6nnen tryTo-Methoden hilfreich sein. Daf\u00fcr werden Step Decorators in der Konfiguration aktiviert:<\/p>\n
        suites:\r\n  acceptance:\r\n    actor: AcceptanceTester\r\n    step_decorators:\r\n      - \\Codeception\\Step\\TryTo\r\n      - \\Codeception\\Step\\ConditionalAssertion<\/pre>\n
        Danach muss Codeception neu gebaut werden:<\/p>\n
        vendor\/bin\/codecept build<\/pre>\n
        Anschlie\u00dfend k\u00f6nnen optionale Elemente abgefragt werden, ohne dass der Test sofort abbricht:<\/p>\n
        public function checkLanguageMenu(AcceptanceTester $I): void\r\n{\r\n    if ($I->tryToSeeElement(static::$CSS_LANG_MENU)) {\r\n        $I->wantTo('click the language selector');\r\n        $I->click(static::$CSS_LANG_MENU);\r\n        $I->seeInCurrentUrl(static::$URL_EN);\r\n    }\r\n}<\/pre>\n
        Das sollte gezielt eingesetzt werden. Nicht jeder Fehler sollte \u201eweich\u201c abgefangen werden. Wenn ein Element zwingend vorhanden sein muss, sollte der Test auch klar fehlschlagen.<\/p>\n
        Testmodus per CSS-Klasse markieren<\/h3>\n
        Manchmal verhalten sich Websites im Testkontext anders als gew\u00fcnscht. Ein Beispiel ist scroll-behavior: smooth, das bei automatisierten Scroll-Methoden Probleme verursachen kann.<\/p>\n
        In solchen F\u00e4llen kann eine Klasse am HTML-Element helfen:<\/p>\n
        $I->executeJS(\"document.documentElement.classList.add('test-runner');\");<\/pre>\n
        Im CSS oder Less kann dann gezielt reagiert werden:<\/p>\n
        .test-runner {\r\n  scroll-behavior: auto;\r\n}<\/pre>\n
        Wichtig ist: Solche Anpassungen sollten den Test stabiler machen, aber keine echten Fehler verstecken.<\/p>\n
        Mehrere Varianten mit @example testen<\/h3>\n
        Wenn derselbe Ablauf mit unterschiedlichen Daten getestet werden soll, k\u00f6nnen Beispiele direkt am Test hinterlegt werden.<\/p>\n
        \/**\r\n * @example { \"startDate\": \"1.1.2010\", \"endDate\": \"1.1.2020\", \"expectedDate\": \"01.01.2010\", \"expectedNumber\": \"27 Suchergebnisse\" }\r\n * @example { \"startDate\": \"1.1.2020\", \"endDate\": \"1.1.2024\", \"expectedDate\": \"01.01.2024\", \"expectedNumber\": \"12 Suchergebnisse\" }\r\n *\/\r\npublic function filterAndOpenDetails(AcceptanceTester $I, \\Codeception\\Example $example): void\r\n{\r\n    $I->wantTo('filter and open details');\r\n\r\n    $I->fillField(static::$CSS_FILTER_DATE_FROM, $example['startDate']);\r\n    $I->fillField(static::$CSS_FILTER_DATE_TO, $example['endDate']);\r\n\r\n    $I->see($example['expectedDate']);\r\n    $I->see($example['expectedNumber']);\r\n}<\/pre>\n
        Das ist praktisch f\u00fcr Filter, Suchfunktionen, Datumsbereiche oder Formularvarianten.<\/p>\n
        Sensible Daten in der .env-Datei speichern<\/h3>\n
        Zugangsdaten geh\u00f6ren nicht ins Git-Repository. F\u00fcr Testlogins nutzen wir Umgebungsvariablen, zum Beispiel:<\/p>\n
        TEST_EXTENSIONS_CSFEUSER_USER='username'\r\nTEST_EXTENSIONS_CSFEUSER_PASS='password'<\/pre>\n
        Im Test k\u00f6nnen diese Werte ausgelesen werden:<\/p>\n
        $I->fillField('Benutzername', getenv('TEST_EXTENSIONS_CSFEUSER_USER'));\r\n$I->fillField('Passwort', getenv('TEST_EXTENSIONS_CSFEUSER_PASS'));<\/pre>\n
        So bleiben Tests automatisierbar, ohne sensible Daten im Code abzulegen.<\/p>\n
        Hilfsmethoden nicht public machen<\/h3>\n
        Gut zu wissen: \u00d6ffentliche Methoden in einer Cest-Klasse werden von Codeception als Tests erkannt.<\/p>\n
        Wenn du Hilfsmethoden schreiben m\u00f6chtest, solltest du sie deshalb protected oder private machen:<\/p>\n
        protected function login(AcceptanceTester $I): void\r\n{\r\n    $I->amOnPage('\/login');\r\n    $I->fillField('Benutzername', getenv('TEST_USER'));\r\n    $I->fillField('Passwort', getenv('TEST_PASS'));\r\n    $I->click('Einloggen');\r\n}<\/pre>\n
        Das h\u00e4lt Tests sauber und verhindert, dass Hilfslogik versehentlich als eigener Testlauf ausgef\u00fchrt wird.<\/p>\n
        Video: Codeception in der Praxis<\/h2>\n
        Wenn du Codeception lieber in Aktion sehen m\u00f6chtest, findest du in diesem Video einen guten Einstieg in automatisierte Tests mit PHP und Selenium:<\/p>\n
        \"Info<\/p>\n
        Dieses Video wird \u00fcber eine externe Plattform (YouTube) gehostet. Das Laden bedarf der Zustimmung unserer Datenschutzbestimmungen.<\/a><\/p>\n
        Einstellung vornehmen<\/a><\/div>\n