Project

General

Profile

Actions

Task #79025

closed

Extract testing framework for TYPO3

Added by Susanne Moog about 7 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
-
Start date:
2016-12-18
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

Since the .gitattributes export change, a lot of base test classes for writing own tests are missing in distribution builds. To get a sustainable future-proof solution, the TYPO3 core testing framework will be extracted to an own component.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Task #79075: Testing Framework: Move fluid base test and fix left-oversClosedSusanne Moog2016-12-22

Actions
Actions #1

Updated by Gerrit Code Review about 7 years ago

  • Status changed from New to Under Review

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

Actions #2

Updated by Gerrit Code Review about 7 years ago

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

Actions #3

Updated by Susanne Moog about 7 years ago

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.
Actions #4

Updated by Gerrit Code Review about 7 years ago

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

Actions #5

Updated by Gerrit Code Review about 7 years ago

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

Actions #6

Updated by Anonymous about 7 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #7

Updated by Gerrit Code Review about 7 years ago

  • Status changed from Resolved to Under Review

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

Actions #8

Updated by Gerrit Code Review about 7 years ago

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

Actions #9

Updated by Gerrit Code Review about 7 years ago

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

Actions #10

Updated by Gerrit Code Review about 7 years ago

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

Actions #11

Updated by Gerrit Code Review about 7 years ago

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

Actions #12

Updated by Gerrit Code Review about 7 years ago

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

Actions #13

Updated by Gerrit Code Review about 7 years ago

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

Actions #14

Updated by Gerrit Code Review about 7 years ago

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

Actions #15

Updated by Gerrit Code Review about 7 years ago

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

Actions #16

Updated by Gerrit Code Review about 7 years ago

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

Actions #17

Updated by Anja Leichsenring about 7 years ago

  • Status changed from Under Review to Resolved
Actions #18

Updated by Adrien Crivelli almost 7 years ago

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 ?

Actions #19

Updated by Adrien Crivelli over 6 years ago

Any news on a migration path ?

Actions #20

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions #21

Updated by Adrien Crivelli about 5 years ago

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.

Actions

Also available in: Atom PDF