Introduce docker based (acceptance) testing from EXT:styleguide

[jpmschuler]

Goal

Integrate the official acceptance tests method from 'EXT:styleguide'.

Acceptance Criteria

• [ ] the official method for acceptance tests are integrated

Additional Information

The official docs refer to EXT:styleguide for acceptance testing, which offers a different approach concerning CI and Composer scripts. However with some adaptions this could be incorporated in EXT:tea to offer the community a coherent one-stop template for QA and testing. The benefits for the extension would be:

1. have acceptance tests (currently EXT:tea just has a static placeholder)
2. introduce runTests.sh to allow all tools to be run docker-based, too. So not only acceptance tests, but also code checks like lint, unit and functional tests.

This should not replace the current CI or current composer scripts (pointing to locally installed tools) but rather add on it, to allow different approaches (e.g. use local tools in general, but have docker-lint for different php versions available, in order to see problems before pushing to CI). If in future it makes sense to point CI to a runTests.sh command, this can be done, but is out of scope of this task.

However each and every available command should be exposed as a composer script for easy discoverability

As this is an epic, it is split in different subtasks which will be created as issues/PRs and linked here. Basically the runTests.sh should be added level by level and it must be decided on how to name and group the composer scripts. Although the acceptance test is the main goal, it is more comprehensible to start with less complex stuff on lower levels, like the static code checks.

• add runTests.sh for the existing static code checks (e.g. lint, sniff, stan)
• add runTests.sh for unit testing
• add runTests.sh for functional testing
• add runTests.sh for acceptance testing
• #450

Considerations: Even if the underlying technology of runTests.sh changes (e.g. docker-compose <=> ddev <=> futuretechXYZ) or even if one would consider switching testing frameworks, this approach fosters abstraction and modularity and thus would make it easier to adapt stuff in the future

[jpmschuler]

(on hold as runTests.sh architecture change supposedly is planned)

[linxpinx]

Do we need this ticket?

[oliverklee]

Yes, we still would like to have some example acceptance tests.