More Related Content
What's hot
What's hot (20)
Similar to Testing microservices with docker
Similar to Testing microservices with docker (20)
Recently uploaded
Recently uploaded (20)
Testing microservices with docker
- 1. Denis Brusnin Jan 2018 Testing Microservices with Docker
- 2. 2 Agenda • E2E Tests: The challenges • Automation Test Strategy • About Docker • Emulating Microservice Dependencies • Benefits of using Docker
- 3. 3 Require staging environment • The Staging environment is not always up to date • You can deploy one version of each microservice at a time • All tests share the same database • Wasting a lot of resources
- 4. 4 Flaky Tests Investigation Time Consuming
- 5. 5 5 Test Execution Speed
- 6. 6 Slow feedback loop • Build • Generate artifacts • Publish artifacts • Deploy artifacts to a staging server • Execute tests
- 7. 7 Normalising the Test Pyramid
- 8. 8 API Automation Test Strategy Frontend C C DataBase MOCK
- 9. 9 IIS ASP.NET Core User API service (example) User API ENVIRONMENT SQL Server HTTP request HTTP response Redis Cache MongoDB External API AppAppApp
- 10. 10 About Docker • Docker is an application build and deployment tool • It is based on the idea that you can package your code with dependencies into a deployable unit called a container • Docker Images are an artefact, essentially a snapshot of the contents a container is meant to run
- 11. 11 Problems solved by Docker • Management of applications • Version control • Distributed management • Low overhead
- 12. 12 Docker Engine • SERVER a daemon process • CLI command line interface • REST API client to server communication via http
- 13. 13 Docker Hub • Image Repositories • Automated Builds • Webhooks • Organizations
- 14. 14 Dockerize Microservice • Create a Dockerfile for your application • Build and run the Docker image • Check the service is running from a container
- 15. 15 A typical API Tests Test Case: User API service should register a new user Arrange Build a POST request with user’s details Act Send the request to User API service Assert HTTP Status code returned, all records in SQL tables were inserted correctly User API Test SQL SERVER
- 16. 16 API Test Framework • Setup • Execute Tests • Clean up Container ASP .NET Core User API DOCKER HOST Container SQL Server HTTP request HTTP response Container Redis Cache Container MongoDB Mock External API Test Orchestrator
- 17. 17 Data Seeding Execute SQL scripts to • Create Database in SQL Server • Create Schemas • Create Tables • Create Views • Seed tables with required data
- 18. 18 Test Example Test Case: User API service should register a new user on Post request Arrange Build a request with user’s details Act Send the request to User API service Assert All records in SQL tables were inserted correctly
- 19. 19 Integrate Tests with the CI Build • Add one more step • Instruct step how to run tests • Parse and analyse build result • Stop the build on any test failure
- 20. 20 Example of failed CI build • Stopping the build on Test Failure • Does not generate artefacts with broken version • No way to deploy the broken version to a staging server • Provide fast feedback
- 21. 21 21 Benefits (or what you can learn from us)
- 22. 22 API Tests running in CI Build • Test services in isolation • Stable and reliable test results • Allow breakages to fail a build • Provide fast feedback • Do not require a staging environment
- 23. Level 19, 60 Margaret Street, Sydney NSW 2000 Australia. www.ofx.com Thank You
Editor's Notes
- The QA environment is not always up to date. Sometimes, some teams simply forget to deploy the last version of their software. As a result, the QA team tests old features. You can only deploy one version of each microservice at a time. what if first engineer needs to test featureA and the second engineer needs to test FeatureB. All our tests run with the same databases … we simply can’t assure the correct isolation of tests Test environment is not coming for free. Having and maintain a lot of environments is expensive.
- Fragile tests do not point broken code.
- Test execution speed Test run of 20 minutes is not accessible for us. If my tests are taking too long to finish due to remote call to external service, I might just mock it and have one single integration test to cover it and not pay a cost in every test. Our team commits code about 10 times per day and making test suite run 10 minutes faster can save 1000 minutes collectively across the team.
- Typical CI/CD pipeline.
- Unit tests are fast running tests that are quick to debug. They cover the bulk of our testing strategy. Integration tests: They run slower than unit tests and test component integration points. Acceptance tests: These are end-to-end (E2E) test cases and consist of happy user journeys and critical failure scenarios, which cannot be tested by unit or integration tests.
- Classical 3-tier application architecture Unit tests are fast running tests that are quick to debug. They cover the bulk of our testing strategy. We write JavaScript unit tests for basic components rendering, events and event handlers, we test all client validation cases for example email or phone fields, etc. Write API service level unit for each of code modules (these are typically classes, functions, dynamic queries, or some other units) to ensure that each unit in isolation performs as it should. All service validation tests such as checking for mandatory fields in incoming requests are also covered by unit tests. Integration Tests run slower than unit tests and test component integration points. For UI we do browser based tests with mocking service calls to API components We avoid any validation testing in integration tests as it’s already covered by unit tests. We also do data contract testing to validate data contracts between Frontend application and API service satisfy each other. E2E E2E acceptance tests with one happy path only.
- Since each test run uses a new, fresh instance if database we need to create all required schemas, table and views required for our Microservice. This steps usually takes no more than two seconds.
- Artifacts were not generated, so no one cannot deploy the broken application. Fast feedback loop.