mirror of
https://github.com/FriendsOfTYPO3/tea.git
synced 2024-12-04 15:56:13 +01:00
[TASK] Rework the testing framework section in the docs (#1480)
This commit is contained in:
parent
82a1df5eda
commit
c99b073bf6
3 changed files with 66 additions and 58 deletions
|
@ -44,7 +44,7 @@ continuous integration.
|
|||
|
||||
Introduction
|
||||
PHPVersionSupport
|
||||
TestingFramework
|
||||
ReleaseBranchingStrategy
|
||||
Environment
|
||||
DependencyManager
|
||||
Running
|
||||
|
|
65
Documentation/ReleaseBranchingStrategy.rst
Normal file
65
Documentation/ReleaseBranchingStrategy.rst
Normal file
|
@ -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.
|
|
@ -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.
|
||||
|
Loading…
Reference in a new issue