PHPackages                             sbuerk/fixture-packages - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Testing & Quality](/categories/testing)
4. /
5. sbuerk/fixture-packages

ActiveComposer-plugin[Testing & Quality](/categories/testing)

sbuerk/fixture-packages
=======================

Helps working with TYPO3 test fixture extensions with typo3/testing-framework functional tests

1.1.3(1y ago)116.8k2GPL-2.0-or-laterPHPPHP ^7.4 || ^8.0CI passing

Since Feb 16Pushed 1y ago1 watchersCompare

[ Source](https://github.com/sbuerk/fixture-packages)[ Packagist](https://packagist.org/packages/sbuerk/fixture-packages)[ RSS](/packages/sbuerk-fixture-packages/feed)WikiDiscussions main Synced 3w ago

READMEChangelog (5)Dependencies (11)Versions (7)Used By (2)

Composer plugin `sbuerk/fixture-packages`
=========================================

[](#composer-plugin-sbuerkfixture-packages)

Important

**EXPERIMENTAL** for now, behaviour and configuration can and will change at any point in a breaking way until baseline implementation has been proven as battle-proof and 1.x is released.

Package `sbuerk/fixture-packages` provides a development context composer plugin, which allows to define paths to scan for composer packages and adopt `autoload`registrations from package as `autoload-dev` registration of the root package, effectly removing the need to register each package autoload manually to have autoloading in place, for example when writing unit, functional or integration tests based on [PHPUnit](https://github.com/sebastianbergmann/phpunit).

Contents
--------

[](#contents)

- [Installation](#installation)
- [Configuration](#configuration)
- [Generated files](#generated-files)
    - [Use generated `FixturePackages`](#use-generated-fixturepackages)
        - [\[TYPO3\] Functional testing with typo3/testing-framework](#typo3-functional-testing-with-typo3testing-framework)
- [FAQ - Frequent Asked Questions](#faq---frequent-asked-questions)

Installation
------------

[](#installation)

Note

The plugin automatically works after the installation and updates the namespace registration when dumping autoloader information.

Tip

You can enforce regeneration of autoload information, for example after adding or removing packages to/from one of the [configured](#Configuration) fixture paths by using `composer dump-autoload`. This is also use-full if autoload configuration for registered packages has changed, for example adding additonal namespaces.

Important

This plugin only registers fixture package autoload configuration as root package autoload-dev configuration when executed in `--dev (DEFAULT)` mode, doing nothing when `--no-dev` is used or has been used.

**Set config to allow plugin**

```
composer config allow-plugins.sbuerk/fixture-packages true
```

**Require composer plugin as development dependency**

Important

The plugin adds additional package namespaces as development dependencies to simplify development setups, mainly for test execution, and usually no need to have it in production installations and **should not be** installed as dependency, special for packages which are libraries, bundles, extensions, plugins and itself required by projects or other packages.

```
composer require --dev "sbuerk/fixture-packages"
```

**One-liner**

```
composer config allow-plugins.sbuerk/fixture-packages true && \
  composer require --dev "sbuerk/fixture-packages"
```

Configuration
-------------

[](#configuration)

[composer](https://getcomposer.org) restricts places for custom configuration within the `composer.json`schema to the extra-section and is used to configure paths to scan for extensions:

```
{
  "extra": {
    "sbuerk/fixture-packages": {
      "paths": {
        "multiple-packages-in-folder/*": [
          "autoload"
        ],
        "pattern-matching/*/matching/same/subpath-in-multiple-places/*": [
          "autoload",
          "autoload-dev"
        ],
        "packages/direct-package-path-containing-a-composer.json": [
          "autoload-dev"
        ]
      }
    }
  }
}
```

If adopting only `autoload` for all path configuration, simplified form **may** be used:

```
{
  "extra": {
    "sbuerk/fixture-packages": {
      "paths": [
        "multiple-packages-in-folder/*",
        "pattern-matching/*/matching/same/subpath-in-multiple-places/*",
        "packages/direct-package-path-containing-a-composer.json"
      ]
    }
  }
}
```

which matches following **recommended** syntax, albeit beeing more to write but more expressive:

```
{
  "extra": {
    "sbuerk/fixture-packages": {
      "paths": {
        "multiple-packages-in-folder/*": [
          "autoload"
        ],
        "pattern-matching/*/matching/same/subpath-in-multiple-places/*": [
          "autoload"
        ],
        "packages/direct-package-path-containing-a-composer.json": [
          "autoload"
        ]
      }
    }
  }
}
```

Note

It is possible to mix them, but requires to use integer indexes, leading to a more brain-melting syntax and should be avoided, as the support is only a co-existence and not technically disallowed for now.

Generated files
---------------

[](#generated-files)

This plugin create two files:

FileDescriptionvendor/sbuerk/fixture-packages.phpReturns an array with fixture package information.vendor/sbuerk/AvailableFixturePackages.phpProvides `AvailableFixturePackages` to work with fixture package information state.Note

These files are not generated to be used casually, but provides a helping hand to be used to integrate it eventually into some framework / testing-framework, for example to allow dynamically load extensions, plugings, bundles or how the framework calls them.

### Use generated `FixturePackages`

[](#use-generated-fixturepackages)

The `FixturePackages` class provides conveniant way to work with the data and provess additional tasks, for example using within [typo3/testing-framework](https://github.com/typo3/testing-framework)bases functional tests to register them and use them by composer package name as extension to load in functional tests.

#### \[TYPO3\] Functional testing with typo3/testing-framework

[](#typo3-functional-testing-with-typo3testing-framework)

The `FixturePackages` class provides a method to adopt fixture packages, which are valid TYPO3 extensions into the `ComposerPackageManager` which allows to use the extension-key or composer package name to configure the extension to load in functional tests.

This is not done automatically yet, but can be done easily by copy & paste

```
/**
 * Automatically add fixture extensions to the `typo3/testing-framework`
 * {@see \TYPO3\TestingFramework\Composer\ComposerPackageManager} to
 * allow composer package name or extension keys of fixture extension in
 * {@see \TYPO3\TestingFramework\Core\Functional\FunctionalTestCase::$testExtensionToLoad}.
 */
if (class_exists(\SBUERK\AvailableFixturePackages::class)) {
    (new \SBUERK\AvailableFixturePackages())->adoptFixtureExtensions();
}
```

into the `FunctionalTestBootstrap.php` file within your extension or project.

Tip

If you do not have the functional bootstrap copied from the testing-framework, you should do that prior to add the snippet. Read the file header along with `FunctionalTests.xml` PHPUnit configuration file already stating that these files \**should* be copied anyway.

Usually, the bootstrap file for functional tests looks similar to the following:

```