Extension testing 

When developing TYPO3 extensions, testing can greatly improve the code quality.

In theory you can test your extension like any other PHP application and extensions. There are however some conventions that make contribution and collaboration easier. And there are some tools that should make your life maintaining an extension easier.

Which tools to use and which rules to apply is highly opinionated. However, having automatic tests is better than no automatic tests, no matter the strategy you follow.

The following test strategies should be applied to improve your code quality.

Table of contents

Linting 

A linting test ensures that the syntax of the language used is correct.

In TYPO3 extensions the following languages are commonly linted:

  • PHP in the supported versions
  • TypoScript
  • YAML
  • JavaScript / TypeScript

Depending on your extension, any other file format can be linted too, if there is tooling for that (for example validating XML files against a XSD schema).

Coding guidelines (CGL) 

If more than one person is working on code, coding guideline are a must-have. No matter which tool you use or which rules you choose to apply, it is important that the rules can be applied automatically.

Common tools to help with applying coding guidelines are PHP-CS-Fixer and PHP_CodeSniffer.

You can find more information in the Coding guidelines section.

Static code analysis 

Static code analysis tools are highly recommended to be used with PHP. The most common tools used are PHPStan and Psalm. No matter the tool you use or the rules and levels you apply: You should use one.

There are also static code analysis tools for TypeScript and JavaScript.

Unit tests 

Unit tests are executing the code to be tested and define input and their expected outcome. They are run on an isolated classes or methods. All relations and services such as database calls, API and curl call must be mocked. Not full instance setup is available. Therefore Dependency injection, the database, configurations and settings and everything done during Bootstrapping is not available.

See also Writing unit tests

Functional tests 

Functional tests, like Unit tests, also execute the code to be tested. Functional test execute the test code within a fully composed TYPO3 instance (non-composer mode) with configured extensions and configuration, having full dependency and extension logic on board and Database backend available.

For this, the TYPO3 Testing Framework is highly recommended, and performs task like filling the database with test data (using fixtures) and activating specific Core or third party extensions (and yours). And, if needed, a backend or frontend user can be logged in.

A functional test will then test the output of a method or if a method changes certain other things like the database or the file system. It can also test more complex functionality of your extension that depends on the TYPO3 environment being present.

See also Writing functional tests

Acceptance tests 

Acceptance testing in the TYPO3 world is about piloting (remote controlling) a browser to click through a frontend generated by TYPO3 or clicking through scenarios in the TYPO3 backend.

See also Writing acceptance tests

Organizing and storing the commands 

There are different solutions to store and execute these commands as some are quite long. For details see Test Runners: Organize and execute tests.