Micro-services Testing Strategy (Part 2) — Micro-services Style of Testing
Welcome back to part-2 of micro-services testing strategy. In first part we saw how old style monolithic testing is not going to help find issues faster in micro-services world. In this post we are going to focus on how testing should evolve as product architecture and development practices changes.
As we saw in first post that product architecture is moving towards breaking it in smaller services(systems), our testing strategy should be focusing and treating each services has an individual component of failure. Testing each component functionality individually will help in detecting issues faster as it will tell us exactly where to find an issue. Let us call these tests as System Tests or Component Tests.
System tests are test suites focusing on individual service functionalities and not end to end product tests. These tests assumes that dependent services (not third party technology stack) of service under test are either faked or mocked. These faked or mocked services returns predefined expected responses based on different requests. This tests ensures if any failure found are due to changes in service under test because all dependent services are mocked. It does sound interesting, isn’t it?
Let us look at visual example of how System test enables micro-services architecture faster delivery mechanism. We will continue with same example as first part, where there are two services, UI service and Backend service which interacts with database.
Now, we will see how System test strategy can be applied here. First we will focus on writing test for Backend services API which supports CRUD functionalities. We will write tests for each API and call these APIs with expected inputs and validate expected outputs. These tests can run whenever there is a change in Backend service which will ensure there are no failure in functionalities, and if there are any failures we know where to look for failures. As Backend service does not have any dependent service, we don’t require any mocked service.
Now let us focus on writing test for UI service which have all UI related functionalities of calling Backend APIs and showing appropriate messages. We will write tests for each UI page in which we will launch each page and perform actions on it and validate expected UI changes. These tests can run whenever there is a change in UI service which will ensure there are no failure in UI functionalities, and if there are any failures we know where to look for failures. Unlike Backend service, UI service is dependent on Backend service for its functionalities to work. Hence, we will write a mock Backend service which will just return valid output responses for all APIs required by UI service. As responses of Backend service are mocked any failure attributes to changes done in UI service.
In above diagram, we can avoid using database by storing responses in mocked service itself. But, by doing that adding any new mocked response will require code change in mocked service and deployment.
With above example we saw that micro-services architecture requires radical shift in testing strategy for faster failures, debuggability and release those services only which are changing with more confidence. System tests are one of those tests which enables you in achieving that.
In next part I will cover kind of failure which is not traceable using System tests and what kind of tests we need to write specific to those failures. For now just give a thought about what kind of failure cannot be caught using System tests.