In the first two tests, we checked and tested the code. In this part, we now want to test what data really flows and what users actually see.
What cucumbers have to do with tests
For all the following tests we use the same test code stack - we use Codeception as a test runner and within it the concept of Behavior Driven Testing, for which the language Gherkin is used.
Gherkin code looks like the following:
As you can see, this syntax focuses on user interaction - CSS selectors are very rarely used, normally a process is always described in a way that a user would use the application.
Due to the rather simple steps and the focus on the actual content of the website, very complex processes can be mapped - and as with the other tests, no logic is hidden. You can also recognize AAA again, where Act and Assert are performed several times in any order.
Acceptance for the functions
But what is really being tested? The example code shows an acceptance test. This controls a browser - either a normal Chrome browser with all features or a headless Chrome within a Docker container in the development and CI environment - and clicks through the finished application.
Acceptance tests are defined by us in such a way that a defined database status stored in git is imported before the test run, which can be optionally supplemented for each test, and then the test is carried out. At the end of each test, the database is reset to the defined status. This allows you to test any process as often as you like - for example, a user installation. If the data status was not always the same, the test could only be carried out once, as a user with a user name can only be created once, and if you had a second test to delete the user, you would always have to carry out these tests one after the other to avoid causing inconsistencies.
These tests always test the complete application stack - web server config, backend and frontend code, CSS (e.g. display: none has an effect on test calls such as "I should see"), database and content, the content of the file system - you name it, you test it. Of course, you have to bear in mind that tests that always render the website or app and click several times and fill out and submit forms can take a correspondingly long time, which is why these tests are not normally used as the main thing, but as a supplement to other, faster tests.
API testing in faster
Our biggest project at the moment is a React application with a TYPO3 backend. The tests took us too long (even with parallelization and the like), especially when we wanted to check the correct data visibility for different permissions and for users who were not logged in. For this purpose, we therefore use API tests, which are also written in Gherkin with Codeception, but use Guzzle internally.
These tests have slightly different steps (example: "Given that the API is logged in as 'user'"), whereby Codeception is controlled so that Guzzle executes the commands, and we then directly test the API URLs, the requests and responses with JSON calls and the database content. The advantage - while simple acceptance tests such as login with a check for the content of the start page require 4 seconds, the API-only stage requires a few milliseconds for a similar test.
Our process often consists of the API checking the different cases and data (without login, different authorizations, valid data, invalid data, data from the past/today/future, etc.) and the FullStack tests then check that the application behaves correctly in a success case and in an error case. In addition, we also test FE's own functions in the FullStack, e.g. that form fields behave differently depending on what a user fills in.
We want to see errors before they become relevant for the customer
We also use Codeception and Gherking for a third testing suite. The FullStack and API tests are always run on every commit and the main git version when changes are made, but only for the version on the development environment. With the third suite, we test functions directly on the customer's live system.
Here we also use the browser and user-like steps, but we make sure that we do not change any data within the tests and that we do not test for changeable data - for example, when calling an activity (as in the example code above) we do not test for an exact date or an exact first and last name, but we test that any date and any name are displayed - this information is enough for us to know that our live system renders the content correctly.
The goal of these tests is that after deployments or after nightly imports and the like, we want to know that the production system is still working, and if not we want to get the info before there is any impact to actual site users. In an older project, there was actually a case where we knew through testing at around 8:00 in the morning that there was a bug - we were able to fix it within a few minutes, and when users started using the application at 8:30 to 9:00, they were able to work flawlessly.
Tools used
For the translation of the Gherkin syntax into Codeception calls, there are methods in the Codeception environment that you can program yourself. We have divided standard steps, which are used again and again, into various Composer packages and published them on Github and Packagist. These repositories can be found in the account/vendor of punkt.de, including a small demo project in which you can read how to use them.
Conclusion
This was the last part of our test series. Applications can now be tested - from code quality to correct functioning on the live system.
Agile testing and process know-how for your team:
Whether you are an agency, an industrial company or an independent development team: if you want to establish or further develop agile testing processes, we will support you with our expertise - whether through practice-oriented workshops or direct, project-related collaboration. We support you from the introduction of agile testing methods and the optimization of existing processes through to the development and implementation of individual testing strategies.
Feel free to contact us to raise your quality assurance and development processes to a new level together!
