README

DRY Experimental base for using runTests.sh in extensions/projects/core

TL;DR: See section "Use of the new runTests.sh in a Composer-based TYPO3 project"

这是什么？

TYPO3 核心的 runTests.sh 文件 (https://github.com/TYPO3/typo3/blob/main/Build/Scripts/runTests.sh) 是非常棒的

• 它集成了 https://github.com/TYPO3/testing-framework，它提供了一个在 TYPO3 框架中执行单元和功能测试的基础

• 它利用 docker 或 podman，提供了容器实现的选项

• 它提供了测试执行时的简单 xdebug 集成

• 它支持广泛的 PHP 和数据库版本，非常适合 CI 矩阵集成

• 低依赖性：只需 docker 或 podman 和 bash，在 Windows WSL、Linux/Unix 和 macOS 上均可使用

• 相同的脚本及其参数可以在本地和 CI 中运行

• 它由 TYPO3 核心积极维护和使用

然而，它有一个很大的缺点

• 不能用于 TYPO3 扩展或基于 TYPO3 的项目，除非将其复制到那些仓库中。runTests.sh 是 TYPO3 单一仓库的一部分，因此不能作为 require-dev 依赖项包含。
• 这意味着，任何修复或任何新功能（添加最新的和最好的 docker 引擎）都需要手动更新脚本。

此存储库作为游乐场，用于评估如何修改 runTests.sh

• 作为 composer 包提供（在 typo3/typo3 核心中维护，作为 subtree split 仓库提供）
• 作为 TYPO3 核心的直接替代品，支持其所有当前功能，而无需更改。这意味着它将需要在 monorepos 的 "Build/Scripts/" 目录中 "生存"。
• 通过分配自我维护的扩展脚本和 "理解" 参数进行自定义
• 提供 "setup" 辅助工具，将 typo3/testing-framework 模板文件（带有修改后的路径）复制到所需位置（待办事项）

主要动机/目标

• "Don't Repeat Yourself" 并尝试防止 "Not Invented Here" 综合征：我们都希望测试能够正常工作，并且工作得很好，而无需复制粘贴东西，并因此接管维护那些脚本。
• "约定优于配置"：runTests.sh 有点固执己见，它不希望支持所有需求，而是提供一个共同的基础。所有需要自定义的东西都应该使用自我维护的附加脚本来完成。这是好事。
• 尽可能少地更改当前的 runTests.sh
• 这并不是说“每件事都需要自定义”，它不应该因为灵活性而变得难以维护，而应该通过更好的灵活性和外部使用反馈来维护。

实验性

所有这些都是实验性的

自行承担风险。

有两种用例

在 TYPO3 核心（单一仓库）中使用新的 runTests.sh

设置将是这个存储库将不再存在。

Build/Scripts/ 中的所有文件都将移动到 typo3/typo3 仓库。

从那里，子树分割将创建一个包，如 typo3/runtests，包含 Build/Scripts 的文件。

这意味着在 Build/Scripts 中需要创建一个 composer.json 文件来包含元数据。那里需要 bin 配置，以及可能需要 require-dev 依赖项。

为了模拟此操作，您可以

• 克隆 typo3/typo3 的 GIT 仓库（main）
• 将此仓库中 Build/Scripts/ 目录下的文件复制到 monorepo 的相同目录下
• 删除 Build/Scripts/runTests.env！对于核心，设置包含在 runTests.sh 中。
• 像以前一样执行 Build/Scripts/runTests.sh。不应该有任何变化。如果有变化，那是一个错误，不是预期的。

在基于 Composer 的 TYPO3 项目中使用新的 runTests.sh

为此，我创建了一个单独的项目，所以您可以

• git clone https://github.com/garvinhicking/tf-basics-project
• cd tf-basics-project
• git checkout runtests （重要）
• composer install
• ./vendor/bin/runTests.sh -s unit
• ./vendor/bin/runTests.sh -s custom -- myStan

此项目包含预定义的配置 runTests.env，它将被使用，还有一些存根测试和配置文件。

甚至可能有一个用于此类 runTests.env 文件的生成器，但现在还不在这个范围之内。

只需查看此仓库，您应该能够将其与任何自定义扩展或项目一起适配

• 一个 composer.json 文件，需要 TYPO3（当然）和 require-dev 此 garvinhicking/typo3-tf-runtests 仓库（目前是这样；未来希望有一个 typo3/runtests 包）
• 提到的 runTests.env 文件
• 用于 phpunit、phpstan 以及您计划利用的其他任何配置文件
• 任何类型的自定义 custom-runTests.xxx.sh 分派者
• 您想测试的 PHP 文件 / 扩展文件
• 可能还需要一些 .ddev 配置，但即使没有 ddev，runTests 也可以完全正常运行。

注意事项

• 有很多变量需要赋值
• 首次提取 "runTests.sh" 的初始操作使得无法使用提供的 runTests.sh 文件来执行 composer install。只有在 composer 首次提取它之后，您才能使用 vendor/bin/runTests.sh -s composerInstall 来使用 dockerized 设置。这是一个经典的鸡生蛋问题。对于 TYPO3 单一仓库实例来说，这不是一个问题，因为 runTests.sh "存在" 那里，不需要 composer 实际提取它。

反馈

是的。请。鼓励人们分享。