DockerCon EU 2015 in Barcelona
Practical tips for using Docker to run tests during development, CI/CD, and different strategies for speeding up the run of your test suite by using parallel pipelines in containers.
The jet tool used to demonstrate parallel testing is available here: https://codeship.com/documentation/docker/installation/
9. Motivators
Update application without breaking things!
Validate functionality of updates
Be able to trust deployment checks (in CI/CD workflow)
Confirm that refactoring didn’t break existing functionality
10. Why do you skip tests?
45%
15%
5%
35% Too slow to run suite 35%
Annoying extra step 15%
Don’t see the point 5%
Slows down deployment 45%
10
11. Frustrators
It takes me an hour to write a single test
My new tests just duplicate existing coverages so there’s no
point (integration overlapping with unit)
My suite fails all the time for no apparent reason…?
It takes my test suite over 20 minutes to run, so I don’t run it
locally
Testing distracts me from my normal development workflow
Setting up a testing environment is a huge pain
It takes too long to deploy when I have a huge test suite
12. Frustrators
It takes me an hour to write a single test
My new tests just duplicate existing coverages so there’s no
point (integration overlapping with unit)
My suite fails all the time for no apparent reason…?
It takes my test suite over 20 minutes to run, so I don’t run it
locally
Testing distracts me from my normal development workflow
Setting up a testing environment is a huge pain
It takes too long to deploy when I have a huge test suite
13. Using Docker can alleviate
some frustrations
associated with testing.
30. You can also run one-off
commands against a service
with Docker Compose.
31. docker-compose run -e "RAILS_ENV=test"
app rake db:setup
docker-compose run -e "RAILS_ENV=test"
app test-command path/to/spec.rb
docker-compose up #-d if you wish
Usual Docker Compose development
environment
Run rake task to set up db
Then run tests against Docker services
39. Relying on CI/CD without
adequate test coverage
is not a great idea.
40. Would you rather…
✔
💩
Find out your code is broken by
seeing a failed run of your CI/CD
system?
Find out your code is broken by
seeing 500s on 500s on 500s in
production?
57. A syntax similar to Docker Compose for
service definition…
57
web:
build:
image: my_app
dockerfile_path: Dockerfile
links:
- redis
- postgres
redis:
image: redis
postgres:
image: postgres
58. And use it to also define testing steps…
58
- type: parallel
steps:
- service: demo
command: ruby check.rb
- service: demo
command: rake teaspoon suite=jasmine
- service: demo
command: rake test
59. - type: parallel
steps:
- service: demo
command: some-test-command
- service: demo
command: another-test-command
- service: demo
command: yet-another-test-command
Each step is run independently in
a container
59
60. - service: demo
command: some-test-command
- service: demo
command: another-test-command
- service: demo
command: yet-another-test-command
And each container may be located in a
range of availability zones
60
70. Highly recommended talks about development, testing,
and lots of interesting stuff: https://speakerdeck.com/searls
Ruby gem for parallel tests: grosser/parallel_tests
Parallel Docker testing: Jet (from Codeship)
CI/CD with Docker: http://pages.codeship.com/docker
Running commands with Docker Compose:
http://docs.docker.com/compose
The perils of Docker-In-Docker: https://jpetazzo.github.io
This talk: slideshare.net/rheinwein
71. —EdsgerDijkstra
“Testing can be a very
effective way to show the
presence of bugs, but is
hopelessly inadequate for
showing their absence.”
71