I have often embarrassed myself GitHub commit wise throwing code at Travis or Circle CI (faster, but no variations of PHP version or database) trying to fix bugs, so why not do this locally and rebase
This is my initial attempt at a Docker based testing rig, and it appears to work. The project is at GitHub - gordonbanderson/SilverStripe-Module-Testing-Suite: Run silverstripe module unit tests in a Dockerized environment and is fairly minimal, instructions are in the README. It boils down to cloning the above project, then cloning your silverstripe module into a directory called module (this name needs to be consistent from a docker-compose mount perspective), and then bootstrapping tests in the same manner as per continuous integration testing.
I have tested this setup with the following projects:
- GitHub - gordonbanderson/silverstripe-sluggable: Configure a field of a DataObject as sluggable, and when saved the slug is auto populated - a very simple module but with 100% coverage and Scrutinizer perfection
- GitHub - gordonbanderson/silverstripe-calendar: Highly flexible calendar system for SilverStripe - an old but complex module I have converted to SS4 for a client, but I felt it was not sufficiently tested and newly written unit tests are an attempt to fix that. Also the reason I am writing this post, in terms of my methodology. It is the same module as this one, https://www.silverstripe.org/blog/managing-events-with-silverstripe-a-new-calendar-module/, featured in an old SilverStripe blog post
- GitHub - silverstripe/silverstripe-blog: Blog module for SilverStripe CMS SilverStripe Blog Module
- GitHub - silvershop/silvershop-core: SilverShop is an e-commerce shopping cart module for the SilverStripe CMS SilverShop core
For all of the above I was able to run the unit tests in an isolated Docker environment and generate HTML coverage reports. I am using a Dell XPS 13 I bought just over a year ago, and the response time is a couple of seconds for a single test, and likes of a minute for the calendar module above, acceptable, and not frustrating.
- Only MySQL is catered for, whilst this is the main database to test against, PostgreSQL is my preferred option and should be an option.
- I have never written any node or behat testing, and the docker image, via the Dockerfile file would need updated accordingly
I hope this post proves useful, and feedback / PRs welcome.