At the TYPO3.org Sprint, our colleague Christian Keuerleber presented a solution based on Codeception that can be used to automatically test websites. The software can be downloaded from GitHub.
During the TYPO3.org sprint in November, Christian presented a tool based on Codeception. It can be used to automatically test the front end of a website, i.e. remotely control the browser and evaluate the results, for example with the help of automatic form entries, clicks and other simulated user actions.
This is how Christian describes the approach:
Every developer has experienced that new changes to a project can make the existing code unusable. In the worst case scenario, these new errors creep into the production system unnoticed. Ideally, to ensure that a website works, you should run automated tests before implementing the code. While most developers are very familiar with functional and unit testing, they often shy away from frontend testing. I want to show how easy it can be to set up and run browser-based tests with Codeception. This way, you can be sure that the frontend won't break down unnoticed.
Christian Keuerleber
The solution can be easily adapted for other TYPO3 installations and is extremely helpful - not only for checking through possible errors during development, but also for regular "monitoring checks". If you want to download it directly, you can find it here on GitHub.
Background: Codeception and frontend testing
Christian had previously presented his solution at the TYPO3 Developer Days. Here is his presentation on YouTube:
After the presentation, Christian was asked whether he would like to implement the solution for the TYPO3.org website. No sooner said than done.
All he had to do was write configuration files and integrate packages. To transfer the package to other websites, the configuration files simply had to be copied over and a few simple parameters changed - done.
The solution offers two areas of application: Monitoring can be used to regularly check whether everything is running on the live system. The acceptance tests, on the other hand, run in a separate environment. There is always a defined data status here, which is reset at the end. The next test then follows. The advantage is that neither the test system nor the live system are affected.
TYPO3.org uses both. Acceptance tests are running for three of the TYPO3 websites, and monitoring tests are also running for these three and another.
Ideal: one tool, one task
How did this development actually come about? At punkt.de, we had been thinking about how we could write tests. We have been carrying out various automated tests for years. The beauty of this Codeception solution, however, is that the browser tests stand alone: Even though Codeception can do other things, this tool is not used for anything else. This allows us to use the tool in a very specific way, but in the right way. One tool, one task.
The ideas are documented, and so a solution package was created. As I said, if you want to take a look at it on GitHub - this way.
"Our projects for TYPO3.org also aim to present examples of best practice. We want to show how to make good websites with TYPO3. Christian's Codeception solution for automated testing is a good example of this."
Thomas Löffler, team leader TYPO3.org
Authors:
Share:
More articles
Our Open Source Learnings 2025
Old certainties are crumbling, new questions are emerging. Who actually decides on technology? How independent are we really? And what role does open source still play? We share our observations from a year that has reorganized many things.
Working at punkt.de - getting started and the first few months
I've been at punkt.de for four months now and in that time I've already taken part in the team days, the Just Do It Day, as a helping hand at a conference and experienced a project going live.
