TYPO3 Core

Patch set 15 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50125

This is the first step of the testing framework extraction…

The complete concept is as follows:

Background¶

After the .gitattributes change, a lot of CI setups were broken as base test classes were suddenly missing. Our immediate solution then was to re-add some of those files by moving them to the classes folder. That did not solve the whole problem however as we had no idea what people “in the wild” were using as base for the tests, the fixtures (especially for the functional tests) were missing entirely and all in all we wanted to have a concept for providing a reliable test base for the future where we could say “this is what we want you to use as base”, so we’d get a fully supported, maintainable package.
After talking to a few people (product team, helmut, some others over time) we came up with the concept of an own package which could be installed via composer as require-dev only - being able to selectively decide which classes and fixtures are part of our testing package as well as supporting CI environments in the best possible way we could think of.

Steps to make it happen¶

1. move all testing framework related stuff into an own folder (which represents the new package),
   1. Move core classes and fixtures
   2. Move other extension base classes and fixtures
2. then separate that package from the core (for example via subtree split) and make it installable on its own.

Patch set 16 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50125

Patch set 17 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/50125

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Patch set 10 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51035

Following this change, how is an extension supposed to test against latest LTS 7.6 and latest sprint release 8.6 ?

I fail to see any viable migration path in the changelog or in this issue, since inheriting from two different classes is clearly impossible in an extension's test case. It also seems impossible to use the testing component by itself to test a TYPO3 7, since its composer.json file declares a dependencies on ^8.5.

Is there anything planned to ease the support of both LTS, 7 and 8, in the future ? or are extension authors on their own and should somehow duplicate testing code ?

Any news on a migration path ?

To answer my own question, the official docs says (emphasis mine):

This documentation assumes an extension is tested with only one major core version. It does not support extension testing with multiple target core versions. Extensions that support multiple core versions at the same time in the same branch are not scope of this document. The core team encourages extension developers to have dedicated core branches per core version. This has various advantages, it is for instance easy to create deprecation free extensions this way.