Scott Stancil, Automattic
Everyone knows that automated tests and checks are only useful if people pay attention to the results, and fix the bugs as they come up. But what do you do if the dev and test environments are isolated, or the developers say the tests are too hard and time consuming to set up and run? Or what if your CI server only runs the test suite when the code is merged, and at that point the developer doesn’t want to wait for them to run before deploying? Developers love the feedback from a good suite of automated checks, but only when it’s convenient and doesn’t interfere with their workflow.
So the answer is to make it as convenient as possible by encapsulating all of the setup for your test environment, and enable the devs to spin it up at will. Remove any roadblocks, and you’ll find that people are eager to run the tests earlier in the development process, which means it’s easier to fix the bugs.
The concepts of DevOps are often intimidating to folks, but I can show you that if you’re capable of writing a script to automate a web browser, you’re capable of building a full test infrastructure and sharing it with the world.
My presentation will cover the concepts of using Docker to contain all of the dependencies of your test environment in one place, which can then be shipped anywhere and run by anyone. By removing barriers to entry, this makes it easy for developers to access the tests and run them against a feature branch before the code is merged. It also ensures that the tests running on your CI server are using the exact same environment as when you run the tests locally, putting an end to the excuse “it worked on my machine”, and leveling the playing field for the entire test team as well.
Scott Stancil, 2017 Technical Presentation, Abstract, Paper, Slides, Video.
