Merge branch 'main' into TASK/use-development-php.ini-on-gitlab-ci

Unit tests for repositories are quite a hassle as we then need to
set up all dependencies in `setUp()` ourselves.

So convert the test to a functional tests where we can rely on the
container to create and initialize the subject for us.

Documentation/Index.rst

@@ -44,7 +44,7 @@ continuous integration.
 
    Introduction
    PHPVersionSupport
-   TestingFramework
+   ReleaseBranchingStrategy
    Environment
    DependencyManager
    Running

Documentation/ReleaseBranchingStrategy.rst

@@ -0,0 +1,65 @@
+.. include:: /Includes.rst.txt
+
+.. _release-branching-strategy:
+
+==============================
+Release and Branching Strategy
+==============================
+
+When maintaining TYPO3 extensions, developers often need to support multiple 
+TYPO3 Long-Term Support (LTS) versions simultaneously. This typically requires 
+a clear release and branching strategy to manage development and maintenance 
+across different TYPO3 versions.
+
+There are two common strategies for managing branches when supporting multiple 
+TYPO3 LTS versions.
+
+.. contents:: Table of Contents:
+   :backlinks: top
+   :class: compact-list
+   :depth: 2
+   :local:
+
+.. _release-branching-strategy-one-branch:
+
+Approach 1: One branch for multiple TYPO3 LTS versions
+======================================================
+
+In this approach, there is a single main branch that receives new features and 
+updates, while supporting multiple TYPO3 LTS versions at the same time.
+
+The downside of this approach is that it may require some version-dependent 
+code switches, which can increase complexity. However, the major advantage is 
+that there is only one branch to maintain, making it easier to implement new 
+features and code changes across all supported TYPO3 versions.
+
+This approach simplifies the maintenance of the extension and is preferred when 
+minimizing maintenance overhead is the primary concern.
+
+.. _release-branching-strategy-multiple-branches:
+
+Approach 2: Separate branch per TYPO3 LTS version
+=================================================
+
+In this approach, there is one main branch for each TYPO3 LTS version. This 
+means that each branch exclusively supports a single TYPO3 LTS version.
+
+The advantage here is that version-specific code can be used without requiring 
+version-dependent switches, reducing complexity in the codebase. However, this 
+approach increases the maintenance burden, as any new features or updates must 
+be applied to each branch individually.
+
+This approach may be necessary when there are significant differences between 
+TYPO3 LTS versions or when you want to avoid version-dependent code.
+
+.. _release-strategy-conclusion:
+
+Conclusion
+==========
+
+The appropriate release and branching strategy depends on the specific 
+requirements of the extension and the TYPO3 versions you are supporting. If 
+reducing maintenance complexity is a priority, using a single branch for 
+multiple versions is often the better choice. However, if you need to tailor 
+your extension for each version, a separate branch for each version may be more 
+suitable.

Documentation/TestingFramework.rst

@@ -1,57 +0,0 @@
-.. include:: /Includes.rst.txt
-
-.. _testing-framework:
-
-=================
-Testing framework
-=================
-
-Extensions usually need 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.
-
-.. contents:: Table of Contents:
-   :backlinks: top
-   :class: compact-list
-   :depth: 2
-   :local:
-
-.. _testing-framework-approach-many-versions:
-
-Approach 1: One branch for many TYPO3 LTS versions
-==================================================
-
-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.
-
-The `Nimut testing framework <https://github.com/Nimut/testing-framework>`__
-can support multiple TYPO3 versions at a time, and
-it provides version-independent abstractions for testing, making it the perfect
-companion for this approach.
-
-This is the approach that we have chosen for this extension as we do not want
-to maintain two branches in parallel.
-
-.. _testing-framework-approach-one-version:
-
-Approach 2: One branch per TYPO3 LTS version
-============================================
-
-With this approach, there 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 <https://github.com/TYPO3/testing-framework>`__
-- which supports only one TYPO3 LTS version at a time - will work just fine.
-

Tests/Functional/Domain/Repository/TeaRepositoryTest.php

@@ -8,6 +8,7 @@ use TTN\Tea\Domain\Model\Tea;
 use TTN\Tea\Domain\Repository\TeaRepository;
 use TYPO3\CMS\Extbase\Domain\Model\FileReference;
 use TYPO3\CMS\Extbase\Persistence\PersistenceManagerInterface;
+use TYPO3\CMS\Extbase\Persistence\Repository;
 use TYPO3\TestingFramework\Core\Functional\FunctionalTestCase;
 
 /**
@@ -31,6 +32,14 @@ final class TeaRepositoryTest extends FunctionalTestCase
         $this->subject = $this->get(TeaRepository::class);
     }
 
+    /**
+     * @test
+     */
+    public function isRepository(): void
+    {
+        self::assertInstanceOf(Repository::class, $this->subject);
+    }
+
     /**
      * @test
      */

Tests/Unit/Domain/Repository/TeaRepositoryTest.php

@@ -1,39 +0,0 @@
-<?php
-
-declare(strict_types=1);
-
-namespace TTN\Tea\Tests\Unit\Domain\Repository;
-
-use TTN\Tea\Domain\Repository\TeaRepository;
-use TYPO3\CMS\Extbase\Object\ObjectManagerInterface;
-use TYPO3\CMS\Extbase\Persistence\Repository;
-use TYPO3\TestingFramework\Core\Unit\UnitTestCase;
-
-/**
- * @covers \TTN\Tea\Domain\Repository\TeaRepository
- */
-final class TeaRepositoryTest extends UnitTestCase
-{
-    private TeaRepository $subject;
-
-    protected function setUp(): void
-    {
-        parent::setUp();
-
-        if (\interface_exists(ObjectManagerInterface::class)) {
-            $objectManagerStub = $this->createStub(ObjectManagerInterface::class);
-            // @phpstan-ignore-next-line This line is 11LTS-specific, but we're running PHPStan on TYPO3 12.
-            $this->subject = new TeaRepository($objectManagerStub);
-        } else {
-            $this->subject = new TeaRepository();
-        }
-    }
-
-    /**
-     * @test
-     */
-    public function isRepository(): void
-    {
-        self::assertInstanceOf(Repository::class, $this->subject);
-    }
-}

composer.json

@@ -54,7 +54,7 @@
 		"php-parallel-lint/php-parallel-lint": "1.4.0",
 		"phpmd/phpmd": "2.15.0",
 		"phpstan/extension-installer": "1.4.3",
-		"phpstan/phpstan": "1.12.5",
+		"phpstan/phpstan": "1.12.6",
 		"phpstan/phpstan-phpunit": "1.4.0",
 		"phpstan/phpstan-strict-rules": "1.6.1",
 		"phpunit/phpunit": "9.6.20",
@@ -62,7 +62,7 @@
 		"seld/jsonlint": "1.11.0",
 		"spaze/phpstan-disallowed-calls": "3.4.0",
 		"squizlabs/php_codesniffer": "3.10.3",
-		"ssch/typo3-rector": "2.8.0",
+		"ssch/typo3-rector": "2.9.2",
 		"ssch/typo3-rector-testing-framework": "2.0.1",
 		"symfony/console": "^5.4.44 || ^6.4.12 || ^7.1.5",
 		"symfony/translation": "^5.4.44 || ^6.4.12 || ^7.1.5",