Integration Testing For Polyglot Ecosystems

DigitalOcean Berlin Meetup @ Factory - 19.04.2016

WHO AM I?

David Worth Software Engineer

SOFTWARE ENGINEER WANTEDHELP US BUILD OUR NEXT BIG THING!

Services

Clients

APIs

MVP! YAY!

PROFIT!

DATA SCIENTIST WANTED!HELP US UNDERSTAND OUR THING!

Models

ClassifiersAPIs

COMPLICATIONS

• 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.

TESTING THEM TOGETHER

GENERAL IDEA

• Write and test an API in one language using standard idioms of the language

• 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

APIClient

API URL Exposed in the Environment by RSpec or Drone

Run Manually or by CI Run Automatically

Exposed to Client Not Exposed

DEMO!

CAVEATS…

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!

SEEDING DATA

• 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 manually.

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 than RSpec

• Drone is slower but potentially parallelization could solve this

QUESTIONS?

DANKE.