First things first - automation

Our tests are executed by GitLab CI after each commit and nightly (on the main branch).

The test days of a night run:

The test result:

Clean, standardized code is easier to maintain

The first step for us is that all developers in the team write the code in the same way. We use various tools for this, depending on the programming language:

• phpcs (php)
• yamllint (YAML)
• eslint (TypeScript and JavaScript)
• stylelint (CSS and SCSS)

Each of these tools works in the same way - it checks the written code for the form that is noted in a corresponding config file and ensures that no developer deviates from it. How strict or open the files are can of course vary depending on the team - apart from phpcs, which uses the code style of php itself defined by PSR and can even check other variants depending on the version. The special thing about these tests is that they are already carried out in the git workflow before a commit, so that no developer can unknowingly transfer code with an incorrect codestyle to the central repository - if it is a work in progress, the step can be temporarily skipped, but this is then a very consciously carried out step.

Future errors are hidden in the details

The next step is phpStan. This tool checks whether the code is written in such a way that data types are maintained and consistent. For example, it is not enough to define an array as an array - Stan forces us to define that it is, for example, an array of numbers with strings as keys. Stan can be configured in 9 (in future 10) levels, each level is stricter than the level before. In our largest project in the team, we currently use level 8 - level 9 would force us to be more precise with mixed as a data type, which in an environment like TYPO3 with sometimes quite flexible collections and arrays would mean greater definition effort.

The checks ensure that data types are clean even through several layers of programming code and also through third-party code, and that functions cannot be used incorrectly, which helps to achieve better consistency in new developments.

The execution of Stan takes a comparatively long time compared to the linting tests, which is why we have decided to only execute them as part of the pipelines and not directly within the git workflow.

Identify security gaps as early as possible

As a team, we have made the decision not to deploy third-party libraries and packages with known security vulnerabilities to customer servers as far as possible. To this end, we execute the commands npm audit --omit=dev and composer audit, which check the packages installed via the corresponding package manager against central CVE databases and note affected installed versions. In the case of npm, we ignore the dev packages, as these are excluded from deployments and are therefore not executed on customer servers anyway.

This step was important enough to us that we perform it as part of the git workflow for every push, and as with the linting steps, a developer can deliberately skip the test - this is necessary in the process, for example, if you do not want to perform multiple package updates in several branches. We can push the affected versions to branches, perform the update in the main branch and then rebase the other branches.

We are also aware that security vulnerabilities can also become known when we do not need to push or when many pipelines are running. We therefore have additional processes to examine existing code and releases, but this is a topic for another blog post.

Outlook

This was the first of 3 articles about our tests. Look forward to part 2 about our handling of unit tests and other tests with phpUnit, and part 3 for API and browser testing.