Situation: We are moving from Docker to Kubernetes. We have PHP applications that have to move from Jenkins to gitlab-ci that are in a bit of a state.

• Original developers aren’t here
• It’s an older PHP framework that’s been working fine quietly by itself for years
• It has different Dockerfiles for local dev, remote dev, and production
• We are using SonarQube for code coverage / health
• We are familiar with behave (python library for user acceptance testing)
• Unit testing is not going to happen with this framework.

I’ve stepped in to assist as I can in the migration, and as part of that I want to:

• Automate the user acceptance testing
• Plug results including code coverage into Sonarqube
• Reduce repetition

Docker duplication

Having different full dockerfiles for local dev vs deployment strikes me as an avenue for error introduction. To remedy this, I’ve added a docker-compose.yml file for localdev that mirrors the kubernetes environment

• Matching host network names

• Matching container names

• Database in local test name now matches the remote test name database

• Local ssl coverage

• Secrets in a secret volume

• Development specific composer requirements are in the require-dev, which are not installed by default

• One of the docker-entrypoint scripts checks the environment variable to see if it’s dev; if it’s dev then it runs composer install with dev so they’re available for it

User acceptance testing

It’s odd not using PHPUnit or PEST for PHP testing, but here we are. behave is well understood by the developers on the team, so it’s easy for everyone to build and drive the user acceptance tests. I’ve advanced them a bit:

• Added a before_feature hook that sets the database to a known state before each feature is run, save for the import feature that requires a blank database
• Added a after_step hook that screenshots failures
• Added the screenshot and reporting directories as artefacts to the gitlab-ci pipeline

Sonarqube

This is the are I’m least certain about, and more desiring feedback. Now, I’m after code coverage over my behave tests1. So, I need the test environment to code cover check, provide that to the test step in gitlab-ci, and have that available to Sonarqube.

• Added pcov code coverage as an extension

• Added phpunit/code-coverage as a require-dev dependency

• Added auto_prepend/ auto_append files that start and record code-coverage as Clover files

• Added a file that the behave server can call to download all the clover tests as a tar

• If the image is deployed with a dev indicator:

• Run composer install with require-dev (ie, not –no-dev).

• Enable the pcov extension

• Put the auto_prepend/ auto_append constructs into the php.ini

• Create a directory for the code-coverage files to go in

• else

• Delete the auto_prepend/auto_append/get-tests.php files

Additionally, in the behave test step itself I’ve added the following after_script

1  after_script:
2    - curl -o tests/behave/reports/test-cases.tar ${BASE_URL}/${DOWNLOAD_FILE}
3    - cd tests/behave/reports
4    - tar xvf test-cases.tar
5    - rm test-cases.tar

So this calls the file created above to download all the code coverages as a tar and extracts them to the same place the behave script puts its reports; so they’re all artefacts that Sonarqube gets access to.

Once the test step in gitlab-ci is run, the test deployment and test database are both destroyed. So nothing left laying around exposing a risk.

Conclusion

This is a lot of mucking around. I think the pcov Dockerfile and providing files to Sonarqube is self contained and neat, but I wrote it so I’m predisposed to like it. Would appreciate feedback/ advice via webmentions.

No I don’t like having user acceptance tests doing code coverage work; but seriously the code is so spaghetti and ancient that we can’t reliably get PHPUnit tests for unit testing components without refactoring the whole thing. And we don’t have time for that. Backlog. ↩︎