mirror of https://github.com/FriendsOfTYPO3/tea.git synced 2024-12-23 03:06:12 +01:00
Mirror of TYPO3 Extension tea, managed by the Best Practice Team https://typo3.org/community/teams/best-practices
Find a file
2021-08-13 14:39:15 +02:00
.ddev [TASK] Run functional tests in ddev (#259) 2021-07-21 13:16:46 +02:00
.github/workflows [TASK] Add separate workflow for composer scripts (#258) 2021-07-21 13:06:59 +02:00
.gitlab [BUGFIX] Fix default template names for GitLab CI (#271) 2021-07-31 20:52:45 +02:00
Classes [CLEANUP] Fix PHP_Codesniffer issues 2019-12-07 12:13:32 +01:00
Configuration [CLEANUP] Autoformat all files (#175) 2020-12-01 23:12:34 +01:00
Documentation [TASK] Add separate workflow for composer scripts (#258) 2021-07-21 13:06:59 +02:00
Resources [TASk] Re-upgrade the XLIFF files to version 1.2 (#230) 2021-04-05 17:26:30 +02:00
Tests [TASK] Enable tests in t3 v10 (#77) 2020-07-23 12:41:27 +02:00
tools [BUGFIX] Fix phpcs fix script (#247) 2021-05-19 13:41:30 +02:00
.editorconfig [TASK] Limit the line length for Markdown files via .editorconfig (#251) 2021-05-15 01:35:25 +02:00
.gitattributes [FEATURE] Add type checking via PHPStan (#218) 2021-03-17 01:08:40 +01:00
.gitignore [TASK] Prepare documentation rendering (#157) 2020-11-29 18:28:34 +01:00
.php_cs.php [TASK] Add more files to php sniffing and fixing (#123) 2020-10-14 11:42:00 +02:00
CHANGELOG.md [FEATURE] Also run the CI build once a week (#160) 2020-11-21 17:58:35 +01:00
CODE_OF_CONDUCT.md [TASK] Upgrade to CoC-v2 (#262) 2021-07-14 13:00:32 +02:00
codeception.yml [CLEANUP] Autoformat all files (#175) 2020-12-01 23:12:34 +01:00
composer.json [BUGFIX] Actually remove .gitignore (#260) 2021-07-08 02:08:36 +02:00
ext_emconf.php [TASK] Allow TYPO3 10 in composer.json and ext_emconf.php (#27) 2019-12-07 12:48:34 +01:00
ext_localconf.php [BUGFIX] Keep the global namespace clean in ext_localconf.php (#39) 2019-12-07 19:15:24 +01:00
ext_tables.sql [CLEANUP] Autoformat all files (#175) 2020-12-01 23:12:34 +01:00
LICENSE [TASK] Change from GPL V3+ to GPL V2+ (#40) 2019-08-08 12:38:56 +02:00
phive.xml [TASK] Clean up the PHIVE configuration file (#272) 2021-08-10 11:56:38 +02:00
phpcs.xml [TASK] Rename dist files (#112) 2020-10-07 14:03:20 +02:00
phpstan.neon [FEATURE] Add type checking via PHPStan (#218) 2021-03-17 01:08:40 +01:00
README.md [TASK] Completely rewrite the README (#270) 2021-08-13 14:39:15 +02:00

Example TYPO3 extension for code quality checks and automated tests

GitHub CI status GitLab CI status Latest stable version Total downloads Latest unstable version License Contributor Covenant

What is this all about?

This Extbase/Fluid-based TYPO3 extension is an example showcase for best practices in continuous integration, automated code checks and unit and functional testing.

You can also use this extension to manage your collection of delicious teas.

Extension manual

The rendered extension manual is available on docs.typo3.org.

Used testing framework and approach to TYPO3 version support

Extensions usually needs to support two LTS versions of TYPO3 in parallel (assuming that they should support all currently supported TYPO3 LTS versions). To achieve this, there are two different approaches, which also affect the choice of a testing framework for unit and functional tests:

Approach 1: single branch with multi-version support

With this approach, there is one main branch that gets new features. It needs to support two TYPO3 LTS versions in parallel.

The downside is that this slightly increases code complexity (as version-dependent code switches might be necessary). The upside is that there is only one branch to maintain, which makes adding new features (and all other code changes) a lot less of a hassle.

As the TYPO3 testing framework supports only one TYPO3 LTS version at a time, you will need to use the Nimut testing framework instead. This testing framework can support multiple TYPO3 versions at a time, and it provides version-independent abstractions for testing.

(This is the approach that we have chosen for this extension as we do not want to maintain two branches in parallel.)

Approach 2: multiple branches for each TYPO3 version

With this approach, there is are two main branches that get new features in parallel. Each branch supports exactly one TYPO3 LTS version.

The upside is that this slightly decreases code complexity (as version-dependent code switches are not necessary). The downside is that there are two branches to maintain, which makes adding new features (and all other code changes) more of a hassle.

For this approach, the TYPO3 testing framework (which supports only one TYPO3 LTS version at a time) will work just fine.

Working locally or Docker-based with ddev

You can run the automated tests and code quality checks either locally (with a local PHP, Composer and database), or you can use ddev for a Docker-based setup.

Composer, PHIVE, GitHub Actions and GitLab CI

Development tools: Composer, PHIVE and dependency hell

Most development tools (e.g., PHP_CodeSniffer) are installed with PHIVE, not with Composer. PHIVE packages each tool with all its dependencies as a separate PHAR. This helps avoid dependency hell (which means that you cannot install or upgrade some tool as the tool's dependencies conflict with the dependencies on another library). It also allows running versions of tools that require a PHP version that is higher than the lowest allowed PHP version for this project.

Some tools are not available via PHIVE, e.g., the Nimut testing framework or the JSON linter. For these tools, we keep using Composer for the time being.

Running the code quality checks locally and in a CI environment

As an example, this extension provides several redundant ways to run the code quality checks. (Running the unit and functional tests is a bit different.) You can copy the corresponding configuration depending on which Git hosting service and which CI platform you plan to use and whether you would like to run the code quality checks locally:

GitHub Actions

This extension has two code-checking workflows for GitHub Actions:

  • one that completely relies on predefined actions: This workflow does not need the development tools to be installed via PHIVE. Use this workflow if you only want to run the code quality checks in GitHub Actions, but not locally.

  • one that uses the PHIVE-installed tools: This workflow uses the development tools installed via PHIVE and calls them using the provided Composer scripts. Use this workflow if want to run the code quality checks locally as well as in GitHub Actions.

GitLab CI

This extension also provides configuration for GitLab CI.

Composer scripts

For most development-related tasks, this extension provides Composer scripts. If you are working locally, you can run them using composer <scriptname>. If you are working with ddev, you can run them with ddev composer <scriptname>. (You do not need to start or build the containers for this as this happens automatically.)

The code-quality-related Composer scripts make use of the PHIVE-installed tools. This means that for non-ddev-based development, you need to run phive install before you can use the Composer scripts.

Available Composer scripts

You can run composer (or ddev composer) to display a list of all available Composer commands and scripts.

Script name Action Tool
ci run code checks the tools listed for the individual checks
ci:composer:normalize normalize composer.json composer-normalize
ci:json:lint lint the JSON files JSON Lint
ci:php run all static checks for PHP the tools listed for the individual checks
ci:php:copypaste check for copy'n'pasted code PHP Copy/Paste Detector (PHPCPD)
ci:php:cs-fixer check the code style PHP Coding Standards Fixer
ci:php:lint lint the PHP files php -l
ci:php:sniff check the code style PHP_CodeSniffer (PHPCS)
ci:php:stan check the types PHPStan
ci:tests:functional run the functional tests PHPUnit
ci:tests:tests run all PHPUnit tests PHPUnit
ci:tests:unit run the unit tests PHPUnit
ci:ts:lint lint the TypoScript files TypoScript Lint
ci:yaml:lint lint the YAML files yaml-lint
fix:php run all fixes for PHP the tools listed for the individual checks
fix:php:cs fix the code style PHP Coding Standards Fixer
fix:php:sniff fix the code style PHP_CodeSniffer (PHPCS)

Running the unit and functional tests

On the command line

To run the unit tests with ddev, use this command:

ddev composer ci:tests:unit

To run the functional tests with ddev, use this command:

ddev composer ci:tests:functional

If you are working locally without ddev, omit the ddev part.

In PhpStorm

General setup for PHPUnit

File > Settings > PHP > Test Frameworks

  • (*) Use Composer autoloader
  • Path to script: select .Build/vendor/autoload.php in your project folder

In the Run configurations, edit the PHPUnit configuration and use these settings so this configuration can serve as a template:

  • Directory: use the Tests/Unit directory in your project
  • (*) Use alternative configuration file
  • use .Build/vendor/nimut/testing-framework/res/Configuration/UnitTests.xml in your project folder
  • add the following environment variables:
    • typo3DatabaseUsername
    • typo3DatabasePassword
    • typo3DatabaseHost
    • typo3DatabaseName

Unit tests configuration

In the Run configurations, copy the PHPUnit configuration and use these settings:

  • Directory: use the Tests/Unit directory in your project

Functional tests configuration

In the Run configurations, copy the PHPUnit configuration and use these settings:

  • Directory: use the Tests/Functional directory in your project
  • (*) Use alternative configuration file
  • use .Build/vendor/nimut/testing-framework/res/Configuration/FunctionalTests.xml

Running the acceptance tests

On the command line

  1. make sure you have Chrome installed on your machine
  2. download the latest version of ChromeDriver
  3. unzip it
  4. chromedriver --url-base=wd/hub
  5. .Build/vendor/bin/codecept run (in another terminal)

In PhpStorm

  1. make sure the "Codeception Framework" plugin is activated
  2. right-click on Tests/Acceptance/StarterCest.php
  3. Run 'Acceptance (Codeception)'

Security

Libraries and extensions do not need the security check as they should not have any restrictions concerning the other libraries they are installed alongside with (unless those would create breakage). Libraries and extension also should not have a version-controlled composer.lock (which usually is used for security checks).

Instead, the projects and distributions (i.e., for TYPO3 installations) need to have the security checks.

Rendering the documentation

After you have cloned the git repository, follow the TYPO3 documentation quickstart guide.