Download the PHP package sbuerk/fixture-packages without Composer

Composer plugin sbuerk/fixture-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.

Contents

• Installation
• Configuration
• Generated files
  • Use generated FixturePackages
  • [TYPO3] Functional testing with typo3/testing-framework
• FAQ - Frequent Asked Questions

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 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

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.

One-liner

Configuration

composer restricts places for custom configuration within the composer.json schema to the extra-section and is used to configure paths to scan for extensions:

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

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

[!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

This plugin create two files:

[!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

The FixturePackages class provides conveniant way to work with the data and provess additional tasks, for example using within 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

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

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:

Use the composer package name now in FunctionalTestCase based tests:

instead of something like

FAQ - Frequent Asked Questions

Q: Will it be possible to add packages autoload to root package autoload in the future?

No. This package is a pure helper during development and there is no need for the provided namespace adoption in productions. Adopting non fully required packages namespaces or the autoload-dev namespaces from packages in production (--no-dev mode) leads to unforeseeable side effects. When this is needed, move your class to the autoload namespace or ask package maintainers to do so.

This is also the reason why this plugin only operates in --dev mode.