• Depending on your protocol responses are “unstructured” (e.g.
JSON) and changes to a client or API may break contracts.
• In Theory tests prevent this, but only if the tests and the tested
code stay in sync with one another.
• Write and test an API in one language using standard idioms of
• Write and test a client in another language using standard idioms
of the language
• Test the client against a live instance of the API run in a
container - automatically
• Tear down all of the infrastructure
• Do it all FAST
API URL Exposed in the Environment
by RSpec or Drone
Run Manually or by CI Run Automatically
Exposed to Client Not Exposed
WAIT FOR IT…
• While the act of starting the container is extremely fast,
application boot may take some time.
• Blindly sleep(2)for “long enough”
• Poll the application (a health endpoint) - with back-off?
IT’S A TRAP!
• These are pure integration tests - do not be tempted to feed data
into a persistence layer depended upon by the system under test.
Data there must “arrive” as if in production - and be cleaned up
THERE ARE OTHER PATHS
• You could Docker Compose for each test (suite) run
• We basically reinvent it here
• Less API Support than raw Docker
• You could simply run your tests with Drone, locally or in CI, rather
• Drone is slower but potentially parallelization could solve this