--- title: "Extension testing" manual: "TYPO3 Explained" version: "12.4" permalink: "https://docs.typo3.org/permalink/t3coreapi:testing-extensions@12.4" source: "Testing/ExtensionTesting.rst" rendered: "2026-10-21T15:29:37+00:00" --- > [!WARNING] > **Attention** > > TYPO3 v12 has reached end-of-life as of April 30th 2026 and > is no longer being maintained. Use the version switcher on the top > left of this page to select documentation for a supported version of TYPO3. > > Need more time before upgrading? > You can purchase Extended Long Term Support (ELTS) for TYPO3 v12 here: > [TYPO3 ELTS](https://typo3.com/services/extended-support-elts). # Extension testing {#testing-extensions} 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](https://docs.typo3.org/permalink/t3coreapi:linting@12.4) - [Coding guidelines (CGL)](https://docs.typo3.org/permalink/t3coreapi:coding-guidelines-cgl@12.4) - [Static code analysis](https://docs.typo3.org/permalink/t3coreapi:static-code-analysis@12.4) - [Unit tests](https://docs.typo3.org/permalink/t3coreapi:unit-tests@12.4) - [Functional tests](https://docs.typo3.org/permalink/t3coreapi:functional-tests@12.4) - [Acceptance tests](https://docs.typo3.org/permalink/t3coreapi:acceptance-tests@12.4) - [Organizing and storing the commands](https://docs.typo3.org/permalink/t3coreapi:organizing-and-storing-the-commands@12.4) > [!NOTE] > **See also** > > See also the [Testing enetcache](https://docs.typo3.org/permalink/t3coreapi:testing-tutorial-enetcache@12.4) > > that used to be displayed on this page. ## Linting {#testing-extensions-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) {#testing-extensions-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](https://github.com/PHP-CS-Fixer/PHP-CS-Fixer) and [PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer). You can find more information in the [Coding guidelines](https://docs.typo3.org/permalink/t3coreapi:cgl@12.4) section. ## Static code analysis {#testing-extensions-static} Static code analysis tools are highly recommended to be used with PHP. The most common tools used are [PHPStan](https://phpstan.org) and [Psalm](https://psalm.dev). 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 {#testing-extensions-unit} 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](https://docs.typo3.org/permalink/t3coreapi:dependency-injection@12.4), the database, configurations and settings and everything done during [Bootstrapping](https://docs.typo3.org/permalink/t3coreapi:bootstrapping@12.4) is not available. > [!NOTE] > Rule of thumb: Unit tests are isolated tests not using real services. See also [Writing unit tests](https://docs.typo3.org/permalink/t3coreapi:testing-writing-unit@12.4) ## Functional tests {#testing-extensions-functional} 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](https://docs.typo3.org/permalink/t3coreapi:dependency-injection@12.4) and extension logic on board and Database backend available. For this, the [TYPO3 Testing Framework](https://github.com/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](https://docs.typo3.org/permalink/t3coreapi:testing-writing-functional@12.4) ## Acceptance tests {#testing-extensions-acceptance} 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](https://docs.typo3.org/permalink/t3coreapi:testing-writing-acceptance@12.4) ## Organizing and storing the commands {#testing-extensions-organization} There are different solutions to store and execute these commands as some are quite long. For details see [Test Runners: Organize and execute tests](https://docs.typo3.org/permalink/t3coreapi:testing-organization@12.4).