5 Tipps and Tricks on Testing Microservices

Presentation at Berlin QA Meetup: http://www.meetup.com/de/Berlin-QA-Because-blame-doesnt-fix-bugs/events/226157475/
Content:
- How to build service tests that need no maintenance on non breaking API changes
- How to mock downstream dependencies
- How to build Consumer Driven Tests with almost no costs
- How to build deployment pipelines for a microservice architecture

Transcript

1. Tipps & Tricks for Testing Microservices Jörg Pfründer Hypoport AG
2. EUROPACE
3. EUROPACE broker software ~20% of Germany's loan mortgages
4. EUROPACE ~20% of Germany's loan mortgages ~ 3 Billion Euro / Month
5. Technologies Java / Groovy Spring Tomcat / Spring Boot MongoDB
6. Deployment Continuous Deployment since 5 years Microservices started ~2 years ago
7. Agenda • Test Pyramid • Microservices' Challenges • Postel's Law for Tests • Express yourself! • Production Code is Test Code • Mock and cheat • Double Check
8. Monolith
10. integration depth number of tests
11. UI Tests → many changes → timing issues → flaky & brittle → high maintenance costs http://www.infoq.com/presentations/integration-tests-scam
12. Avoid testing many equivalence classes with UI tests. → test on the lowest sensible level
13. Microservices Split large software into small pieces that can be deployed independently → fast development → fast deployment → fast feedback → fast bugfixing
14. Loose Coupling
16. #1 Postel‘s Law for Tests
17. String comparison via equals() Problem #1 {"firstname" : "John", "surname" : "Doe" }
18. String comparison via equals() JSONassert (XMLAssert) Problem #1 { "firstname" : "John", "surname" : "Doe" }
19. String equals JSONassert (XMLAssert) ?? Problem #1 { "firstname" : "John", "surname" : "Doe", "name" : "John Doe" }
20. String equals JSONassert (XMLAssert) Problem #1 { "id" : 9586729475, "firstname" : "John", "surname" : "Doe", "name" : "John Doe" }
21. • Only very few elements of the UI are tested • Most parts of the UI untested Inspiration: UI Automation
22. • JSONpath (Xpath) • Groovy RESTClient (SOAPClient) Trick #1 { "id" : 9586729475, "firstname" : "John", "surname" : "Doe", "name" : "John Doe" }
23. Be conservative in what you do, be liberal in what you accept from others. Jonathan Postel RFC793 Trick #1: Postel‘s Law Lizenziert unter Attribution über Wikimedia Commons http://commons.wikimedia.org/wiki/File:Jon_Postel.jpg#mediaviewer/File:Jon_Postel.jpg
24. #2 Express yourself!
25. Problem #2 http://geek-and-poke.com/geekandpoke/2013/7/28/tdd (Creative Commons 3.0 Licence – intermediate picture deleted)
26. Problem #2 http://geek-and-poke.com/geekandpoke/2013/7/28/tdd (Creative Commons 3.0 Licence – intermediate picture deleted)
27. Inspiration: Webdriver Page Object
28. Trick #2: Response Object • Encapsulate the service's answer into a response object • The response object should provide methods that represent the business perspective • The response object implements these methods internally using the JSON or XML structure
29. Trick #2: Response Object assert userRequest.isSuccessful() == true def response = userRequest.response assert response.getFirstName() == "John" assert response.getSurname() == "Doe"
30. Trick #2: Response Object more comprehensible encourages reuse
31. #3 Production Code is Test Code
32. Problem #3 Loose Coupling
33. Trick #3 Contract Tests { "id" : 9586729475, "firstname" : "John", "surname" : "Doe", "name" : "John Doe" }
34. Trick #3: Contract Tests Formal specification of the contract by DSL • Pact https://github.com/realestate-com-au/pact • Pacto https://github.com/thoughtworks/pacto
35. Trick #3: Production Code is Test Code Use the client's implementation code for tests: Consumer Driven Tests in a Consumer Driven Test Suite (CDTS)
36. Trick #3: Production Code is Test Code Consumer μ-Service Service Provider Consumer Driven Test Suite
37. Trick #3: Production Code is Test Code Consumer Driven Tests Technology agnostic?
38. Trick #3: Production Code is Test Code Almost technology agnostic: #!/bin/bash waitUntilSUTstarted curl ­s "$TEST_ARTIFACT_URL" > "cdts.jar" java $PROPERTIES ­jar cdts.jar RESULT=$? rm ­f cdts.jar if [ "$RESULT" ­ne "0" ]; then error "Contract tests failed!!!" fi
39. #4 Mock and cheat!
40. Problem #4: Downstream Dependencies ? μ-Service under Test Downstream Dependency
41. Trick #4: Mock and cheat! Mock μ-Service under Test
42. #4: Mountebank • www.mbtest.org • Runs on node.js • standalone installation or via npm
43. μ-Service under Test Mountebank #4: Mountebank
44. POST /imposters { "port": 4545, "protocol": "http", "stubs": [ { "responses": [ { "is": { "statusCode": 200, "headers": { "Content-Type": "text/html; charset=utf-8" }, "body": "<html><body><h1>Test</h1></body></html>" } } ], "predicates": [ { "startsWith": { "path": "/dokumente/download" } } ] }
45. μ-Service under Test Mountebank #4: Mountebank
46. #4: Wiremock • www.wiremock.org • java technology • just embed the library in your project • configuration via native java method calls • no config port
47. #4: Wiremock
48. Who should start Wiremock? The Test The Application
49. Who should start Wiremock? The Test • Mocks and test cases are a logical unit • Separation of test code and production code The Application
50. Who should start Wiremock? The Test • Mocks and test cases are a logical unit • Separation of test code and production code • Complicated setup The Application
51. Who should start Wiremock? The Test • Mocks and test cases are a logical unit • Separation of test code and production code • Complicated setup The Application • Faster startup • Less configuration • Easier local development
52. Trick #4: Mocking Services www.wiremock.org www.mbtest.org (Node.js) github.com/dreamhead/moco github.com/azagniotov/stubby4j github.com/vcr/vcr (RUBY)
53. #5 Double check!
54. v3 v4 v2 v7 Problem #5: Versioning & CD
55. Problem #5: Versioning & CD ? μ-Service A μ-Service B μ-Service C μ-Service D
56. Trick #5: Double check!
57. Only TWO Versions! 1. Currently productive version 2. The new version -> NO version management
58. Unbreak Changes 1. Old schema { "id" : 9586729475, "firstname" : "John", "surname" : "Doe", "name" : "John Doe" }
59. Unbreak Changes 1. old schema 2. compatibility version that supports the old AND new schema { "id" : 9586729475, "firstname" : "John", "nachname" : "Doe", "name" : "John Doe", "displayName" : "John Doe" }
60. Unbreak Changes 1. old schema 2. compatibility version that supports the old AND new schema 3. remove support for old schema { "id" : 9586729475, "firstname" : "John", "nachname" : "Doe", "name" : "John Doe", "displayName" : "John Doe" }
61. Trick #5: Double check What if accidentially two incompatible services roll out at exactly the same time?
62. Trick #5: Double check • Small Changesets
63. Trick #5: Double Check • Small Changesets • Real Continuous Deployment
64. Trick #5: Double check • Small Changesets • Real Continuous Deployment • Talk!
65. Trick #5: Double Check with more speed
66. Trick #5: Double check with more stability
67. Trick #5: Double check - the future Docker helps here: - standardized deployment - standardized environment
68. Tilted Pyramid
69. Tipps & Tricks 1. Postel‘s Law: No detailed tests on high level 2. Express yourself: Abstractions with response objects 3. Mock and Cheat: Use test doubles for downstream dependencies 4. Production Code is Test Code: Simple consumer driven tests 5. Double Check: CDTS in the deployment pipeline
70. Literature • Mike Cohn: http://www.mountaingoatsoftware.com/blog/the- forgotten-layer-of-the-test-automation-pyramid • Ian Robinson: Consumer-Driven Contracts: A Service Evolution Pattern http://martinfowler.com/articles/ consumerDrivenContracts.html • Brandon Byars: Enterprise Integration Using REST http://martinfowler.com/articles/enterpriseREST.html • Jay Fields: Working Effectively with Unit Tests https://leanpub.com/wewut • Sam Newman: Building Microservices