Use g1a/composer-test-scenarios to test more php versions.

[greg-1-anderson]

I noticed that the tests for this project were failing on php 7.2. phpunit 4 does not like php 7.2, but on the flip side, phpunit 6 does not like any php prior to 7.0. The composer-test-scenarios project was designed specifically for this sort of instance.

You may or may not want to test with all of the permutations in the included matrix, but here they are to prove they work (or to fiddle with them until they work).

[greg-1-anderson]

Here's the blog post:

https://pantheon.io/blog/highest-lowest-testing-multiple-symfony-versions

[webflo]

Great improvement. Is it possible to gitignore the scenarios folder and create it in Travis CI in the install step?

[greg-1-anderson]

I should probably explain the purpose of the scenarios folder in the documentation. This directory is in essence like your composer.lock file for your different test scenarios. You therefore must commit it to your repository so that your dependencies will be consistent between tests. If you have a scenario that is only ever used with highest or lowest tests, then you can create it with --no-lockfile, and that scenario will not need an entry in the scenarios directory. However, even if you create all scenarios without a lockfile, I still stash a setup script there, because I need it on a fresh project clone so that things work correctly when folks git clone ; composer install a project.

[greg-1-anderson]

When the composer scenarios are complicated (e.g. multiple versions of Symfony), then the composer test scenario scripts provide a lot of convenience. For example, you can run composer scenario symfony2 and then do ad-hoc testing with Symfony 2 dependencies.

In the case of this project, the only scenario we have is phpunit4. It would be easy enough to dispense with composer test scenarios and just adjust the composer.json with several lines of scripts in the travis file, controlled by multiple environment variables in the test matrix. Later today I'll make a second PR to show the alternative for the sake of comparison.

[greg-1-anderson]

The other question is, would it be an improvement to rename the scenarios folder to something else, e.g. .scenarios (hide it from casual observation), scenarios.lock (make it clear that this is like composer.lock) or perhaps even .scenarios.lock (both at once)?

[greg-1-anderson]

CircleCI just transitioned from circle.yml to .circleci/config.yml, so I decided that the hidden .scenarios.lock was probably most appropriate.