[bmack]

Functional test instances can now be provisioned as composer mode installations. Until
now every instance is a classic mode installation, although composer mode is what most
projects run, so a whole installation layout - config/ and var/ beside a public/
document root, packages resolved from a package artifact, assets in _assets/ - never
gets tested.

TYPO3_TESTING_INSTANCE_MODE=composer

Nothing changes without the switch

Classic mode stays the default and behaves exactly as before: same instance path, same
database name, same setup steps, same API. In particular:

• no public method of Testbase or FunctionalTestCase changes its signature
• no new protected methods on FunctionalTestCase that could collide with methods of
  test cases in extensions
• every composer mode code path runs only when the variable is set

Composer mode needs TYPO3 v14.3 or later, and says so with a clear message when it is
enabled on an older version.

How a composer mode instance is built

An instance is not its own composer installation. A shared installation containing every
extension the test cases load is built once per run (TYPO3 Core does that with
Build/Scripts/setupFunctionalComposerSuperset.php, TYPO3_TESTING_SUPERSET_PATH can
point elsewhere). Each instance borrows its vendor tree:

<instance>/vendor                 -> <shared>/vendor
<instance>/public/_assets         -> <shared>/public/_assets
<instance>/config/system          own configuration
<instance>/var/testing-framework  own package artifact
<instance>/public                 own document root, fileadmin, typo3temp/assets
<instance>/var                    own caches and logs

The package set of a test case is written into the instance as its own package artifact,
derived from the one the installer plugin built for the shared installation: every
package stays known, only the ones the test case loads are active. It is the composer mode
counterpart of the PackageStates.php of a classic instance, and TYPO3 reads it with its
own ComposerPackageArtifact. TestingBootstrapRunner points Bootstrap at it by
overriding createPackageCache(), so TYPO3 itself needs no change.

Classes are not loaded from the shared installation. The root autoloader already maps
every extension, so no second autoloader is registered and no third party package is
loaded twice.

What to look at

1. The installed-but-inactive packages. In a real composer installation, installed
   and active are always the same set. Here the shared installation installs everything
   and each instance activates a subset. This is the one place the model departs from
   reality.
2. SystemEnvironmentBuilder::determineCurrentScript(). On the CLI, composer mode
   reports the console binary as the entry script. Functional tests are CLI processes
   simulating web requests, and NormalizedParams derives the site path from the entry
   script, so every generated link lost its leading slash. In composer mode the entry
   script is public/index.php now, as for a web request.
3. Console commands in sub processes. EXT:core/bin/typo3 finds its autoloader
   relative to itself, which resolves outside the instance. Composer mode instances get a
   generated entry point instead, with the instance paths written in, because Symfony
   Process does not pass on putenv() values.

For tests that run in both modes

TestInstance (internal, used by TYPO3 Core) has three helpers for tests that must
work in either layout:

• boot(), for tests that bootstrap an application themselves
• getCliEntryPoint(), for console commands in a sub process
• getAppRelativePublicPath(), for PKG:typo3/app: resource identifiers, which are
  relative to the project root and not the document root

Verification

TYPO3 Core functional suite on SQLite, in 4 chunks as in CI:

• Classic mode, this change vs. the unmodified testing framework: the same tests in
  every chunk. The only differences come from the Core companion patch's use of
  TestInstance, which does not exist without this change.
• Composer mode: works end to end, including console sub processes and frontend
  requests. The remaining failures are in Core tests added or changed since the companion
  patch was prepared, which assume the classic layout. These tests call Bootstrap::init()
  directly, link into typo3conf/sites, or use the new file storage configuration. The
  companion patch is being updated for them.

Lint (PHP 8.2), CGL and the unit tests of this package are green.