| Cool post, and pretty spot on. I've been doing this with Ruby apps, many of which interact with a
browser, and I have some additional thoughts: - If you're running MacOS Catalina, make sure that you are using the Python version of
Docker-Compose, not the compiled version that Homebrew installs. There's a bug with
PyInstaller where it needs to fetch resources from the Internet after running any Compose command.
This can add significant startup latency. You can you `pip3 install docker-compose` to install the Python version over the "Homebrew"
version.
- If you want to do quick contract testing against your API without running a ton of code, Dredd
is your answer. It runs tests against your OpenAPI YAML docs, which is super nice.- Compose services start asynchronously, meaning that your database might not become available by
the time that your unit tests run. While I would recommend mocking database responses during units
and spinning up local database instances for contract or integration tests, if you need to do
this, ensure that your tests have some kind of code that synchronizes your database against your
unit tests. - Speaking of databases, data within containers is ephemeral, meaning you _will_ lose it after
every test run! Remember to use the 'volumes:' block to specify where you want your PG data
volumes stored, and if you're using your Git repository for storing this data, ensure that you
.gitignore it (unless you need to have test data pre-populated for your tests to work) - If you're going to do any browser automation in Compose, the easiest path will be to use
Selenium Hub and have separate Compose services for every browser under test. I have an example
of that here: https://github.com/carlosonunez/bdd-demo - If you're doing any unit testing for functions that will eventually run within AWS Lambda (or
any cloud-FaaS, really), and your functions rely on a headless browser, I would _really_ recommend
finding the most lightweight WebKit browser that you can find over Chrome and then
use the `lambdaci/lambda` Docker image for EVERYTHING. I had a REALLY
hard time getting Chrome to work within Lambda even though my units were passing, despite
disabling shared memory, GPU usage and all that other jazz. I eventually landed up using
PhantomJS (deprecated) to do what I needed to do. Node has better support for Chrome on Lambda,
but only marginally so. - `docker-compose run` does not expose ports to your host; `docker-compose up` does! - As you get more familiar with Compose, you will be tempted to use Docker within Docker. Avoid it
if you can. Making host volumes accessible to nested Docker containers is a MAJOR pain in the ass
and adds a lot of complexity. - As a general unit testing tip, you shouldn't need any network access for your unit tests. if your
unit tests need internet access for anything other than fetching dependencies, then you might want
to consider refactoring your tests. |
From docs: "Run command with the service's ports enabled and mapped to the host." https://docs.docker.com/compose/reference/run/
Also, for anybody wondering about "synchronization" solutions, I have found dockerize to be very useful. https://github.com/jwilder/dockerize