Integration Testing for Polyglot Ecosystems

62 views

Published on

This brief talk introduces a Docker-backed testing harness for conducting integration tests on systems that are built in multiple languages and on multiple platforms.

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
62
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Integration Testing for Polyglot Ecosystems

  1. 1. Integration Testing For Polyglot Ecosystems DigitalOcean Berlin Meetup @ Factory - 19.04.2016
  2. 2. WHO AM I? David Worth Software Engineer
  3. 3. SOFTWARE ENGINEER WANTED HELP US BUILD OUR NEXT BIG THING! Services Clients APIs
  4. 4. MVP! YAY!
  5. 5. PROFIT!
  6. 6. DATA SCIENTIST WANTED! HELP US UNDERSTAND OUR THING! Models Classifiers APIs
  7. 7. 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.
  8. 8. TESTING THEM TOGETHER
  9. 9. 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
  10. 10. APIClient API URL Exposed in the Environment by RSpec or Drone Run Manually or by CI Run Automatically Exposed to Client Not Exposed
  11. 11. DEMO!
  12. 12. CAVEATS…
  13. 13. 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?
  14. 14. 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.
  15. 15. 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
  16. 16. QUESTIONS?
  17. 17. DANKE.

×