A microservice architecture builds software as a suite of collaborating services. Microservices are often integrated using REST over HTTP.\u00a0They\u00a0connect over networks\u00a0and make use of \u201cexternal\u201d data stores.<\/p>\n
Microservice architecture, or simply microservices, is a distinctive method of developing software systems that focuses on building single-function or single\u2013purpose modules with well-defined interfaces and operations.\u00a0This trend has grown popular recently as enterprises look to become more Agile and move towards a DevOps and continuous testing\u00a0approach<\/a>. Microservices can help create scalable, testable software that can be delivered very often, as frequently as weekly and daily.<\/p>\n Microservices architecture allows admins or users to load just the required services, improving deployment times, especially when packaged in containers.<\/p>\n Microservices provide changes only when and where they\u00a0are needed. With a microservices architecture, the application monitors each functional component.<\/p>\n It would help if you\u00a0had a different microservices testing strategy. They\u00a0follow a different architecture\u00a0and\u00a0have\u00a0many integrations with other microservices within one\u2019s organization\u00a0and\u00a0from\u00a0the\u00a0outside world (3rd\u00a0party integrations).\u00a0Additionally, these\u00a0require\u00a0much collaboration among different teams\/squads developing individual microservices. Moreover, they\u00a0are single-purpose services\u00a0and\u00a0are deployed independently and regularly.<\/p>\n Before\u00a0discussing\u00a0the various\u00a0microservices testing strategies, let\u00a0us\u00a0look at a self-explanatory diagram to\u00a0understand the composition of microservices.\u00a0\u00a0<\/span><\/p>\n Different types of testing need to be performed<\/a> at different layers of microservices. Let us look at them using an illustration of three microservices collaborating\/working closely. Assume Microservices A, B, and C are working together<\/a> with many other Microservices (not shown in the picture). The following diagram illustrates all testing types and their boundaries by taking one microservice (Microservice B) as an example.<\/p>\n A unit test exercises the smallest piece of testable software<\/a> in the application to determine whether it behaves as expected.<\/em><\/p>\n Unit tests are typically written at the class level or around a small group of related classes. The smaller the unit under test,\u00a0the easier it is to express the behavior using a unit test.\u00a0With unit testing, you see an essential distinction based on whether or not the unit under test is isolated from its collaborators.<\/p>\n In connection with the images above, unit tests are crafted explicitly for the internal modules within a given microservice, addressing each internal module individually. Techniques such as employing test doubles, stubs, and mocking are often utilized to substitute dependencies where necessary. Typically, unit tests are authored by your development team. In your capacity as a QA engineer, it is essential to ensure that unit tests<\/a> are included as an integral part of their code commits.<\/p>\n Unit testing\u00a0alone does\u00a0not provide a guarantee\u00a0about the behavior of the system.\u00a0You\u00a0must address the coverage of the internal modules when they work together to form a complete\u00a0Microservice.\u00a0You\u00a0must also manage the interactions the modules make with remote dependencies.<\/p>\n An integration test<\/a> verifies the communication paths and interactions between the modules\u00a0and their dependencies.<\/em><\/p>\n Integration tests collect modules and test them as a subsystem to verify that they collaborate as intended to achieve some larger behavior.\u00a0Examples of module integration tests demonstrate the communication between\u00a0Repositories and service Layer,\u00a0Service Layer\u00a0and resources,\u00a0etc.\u00a0Integration test\u00a0examples for external dependencies include\u00a0the tests between\u00a0data stores, caches,\u00a0and other microservices.<\/p>\n You often write an extended version of your unit tests on the internal modules and start calling them Integration Tests. Thus,\u00a0it is a good idea to delegate the job of writing automated integration tests<\/a> to your developers because it is easy for them to use the existing unit test frameworks to extend for Integration Tests. It needs them to use the actual instances of the internal modules involved (Ex: API Resources, Service Layer, DBs, and Message Queues,\u00a0etc.).\u00a0Testers can choose to do this activity provided the infrastructure team is ready to give you\u00a0an\u00a0integration environment with all the actual dependencies deployed.<\/p>\n Write just a handful of test cases in both cases; do not automate an exhaustive list, as other testing types will cover the complete functional testing (Component Tests). These tests should act like a health check\u00a0activity\u00a0between the integration layers with a small test suite size.<\/p>\n With Unit and Integration Testing,\u00a0you\u00a0can gain confidence in the quality of the internal modules that make up the microservice. However, you\u00a0cannot guarantee that the microservice works together to satisfy the business requirements.\u00a0You\u00a0must end-to-end\u00a0test\u00a0the integrated microservice by isolating it from external\u00a0dependencies\u00a0and other collaborating microservices.<\/p>\n A component test verifies the end-to-end functionality of\u00a0the\u00a0given microservice in isolation by replacing its dependencies with test doubles and mock services.<\/p>\n In a microservice architecture, the components are the services themselves. By writing tests at this granularity, the contract of the API is driven through tests<\/a> from a consumer’s perspective. Isolation of the service is achieved by replacing external collaborators with test doubles and using internal API<\/a> endpoints to probe or configure the service.<\/p>\n The above microservice diagram shows that component tests focus\u00a0on\u00a0one microservice at a time. For example,\u00a0testing Microservice A in isolation,\u00a0and then B,\u00a0and then C,\u00a0and so on.\u00a0If Microservice A collaborates closely\u00a0with Microservice B and you want to test Microservice A in isolation,\u00a0then you would replace Microservice B with a mock service, integrate it with Microservice A,\u00a0and try it end-to-end.<\/p>\n Testing such components in isolation provides many benefits:<\/p>\n QA team is expected to define the coverage,\u00a0write\u00a0test scenarios,\u00a0and automate\u00a0them all.\u00a0You\u00a0can\u00a0use standard\u00a0API testing tools such\u00a0as\u00a0SoapUI, ReadyAPI,\u00a0REST-assured,\u00a0and HTTP\u00a0Client.\u00a0You\u00a0can see this as a typical web service testing<\/a>.\u00a0This involves extensive mock services to replace the\u00a0dependencies\u00a0to test microservices in isolation.\u00a0Wiremock, MockLab, MockableIO, and ServiceV are\u00a0a\u00a0few examples.<\/p>\n With Unit,\u00a0Integration,\u00a0and Component Testing Microservices,\u00a0you can\u00a0achieve high coverage of\u00a0modules\u00a0that make up the microservice. However, the\u00a0quality\u00a0of the complete solution is not assured unless your tests cover all the microservices working together. Contract Testing of external\u00a0dependencies\u00a0and end-to-end testing of the whole system help\u00a0provide this.<\/p>\n A contract Test is a test at the boundary of an external service verifying that it meets the contract expected by the consuming service.<\/em><\/p>\n If two microservices or a microservice and its dependent services are collaborating,\u00a0then there forms a contract between them. Suppose Microservice A and B are collaborating where Service A interacts with Service B by sending\/seeking some data\u00a0and Service B\u00a0is\u00a0responding\u00a0to Service A for all its incoming requests. In that case, there forms a contract between Service A and B.\u00a0Here,\u00a0Service A\u00a0is known as the\u00a0consumer, and Service B as a provider.<\/p>\n Contract testing takes place\u00a0in two steps:<\/p>\n This way, the provider team can keep\u00a0all\u00a0their consumers (different groups within their organization or other clients\/customers) updated on the schema changes. This will help the consumer plan the change management well ahead.<\/p>\n QA teams from both parties are expected to produce contract tests.\u00a0Contract testing also employs an interim mock service as\u00a0a\u00a0bridge between the consumer and provider\u00a0since\u00a0the testing takes two steps\u00a0in\u00a0different timelines.\u00a0PACT\u00a0is a great example of implementing contract testing<\/a>.<\/p>\n Contract tests are not functional tests. They are defined for the entire microservice and focus more on input\/output formats and types than actual values. Hence,\u00a0the suite size is expected to be smaller than the component test suites.<\/p>\n The\u00a0system as a whole meets business goals irrespective of the component architecture in use. The whole system should be\u00a0treated\u00a0as a black box, and the tests must\u00a0be\u00a0exercised\u00a0as much\u00a0on\u00a0the fully deployed system as possible, manipulating it\u00a0through\u00a0public interfaces such as GUIs and service APIs.\u00a0Strictly, no concept\u00a0of mocking is observed here.<\/p>\n As a microservice architecture includes more moving parts for the same behavior, end-to-end tests provide value by adding coverage of the gaps between the services.\u00a0You do not\u00a0have to write tests for each of the microservices\u00a0involved.\u00a0You\u00a0just need to find\u00a0a\u00a0few high\u2013level business workflows or user journeys (end-to-end journeys) and automate them.\u00a0Any UI and API\u00a0automation library\u00a0can be used. Selenium, in combination with REST-assured,\u00a0is a best example test framework.<\/p>\n Writing and maintaining end-to-end tests can be very difficult, write as few end-to-end tests as possible.<\/em><\/p>\n While the\u00a0importance of\u00a0performance\u00a0testing<\/a>\u00a0is widely known,\u00a0it is worth mentioning at what level you perform this for microservices.\u00a0It is recommended that you do it\u00a0at two\u00a0levels:<\/p>\n It is better to have separate performance environments to do this. QA team can use any lightweight tool, such as JMeter and Locust, to measure the performance of each microservice. I recommend approaching specialized performance teams to do a detailed performance analysis of the entire system when all the microservices are deployed and integrated to work together.<\/p>\n \u00a0<\/span>Microservices\u00a0<\/span><\/b>Test Pyramid<\/span><\/b>\u00a0<\/span><\/p>\n Unit Tests\u00a0<\/strong>are at the bottom\u00a0of the pyramid\u00a0with comparatively larger test suites\u00a0in size. They are written for each microservice and all of their internal modules\/components. The execution time is considered very\u00a0low,\u00a0but the scope of testing is higher with granular coverage.<\/p>\n Component Tests\u00a0<\/strong>are\u00a0second to Unit Tests in size as this is nothing but the full\u2013functional test suite for all microservices. You will cover the tests for all possible cases, boundary values, edge cases, positive and negative cases,\u00a0etc.<\/p>\n Contract Test\u00a0<\/strong>suites\u00a0have a\u00a0considerably good\u00a0size with a look and feel similar to component test suites,\u00a0but the coverage is limited just to the contracts, which means the input and output formats and types. You do\u00a0not have to test the functionality. Example tests for an API would be a test for 200 responses, another for 400 responses,\u00a0and one for 415 responses if applicable for each resource URI\/endpoint.<\/p>\n Integration Tests\u00a0<\/strong>are usually only a handful by, writing 2 or 3 tests for each integration among the internal modules and external APIs. The size is considerably small.<\/p>\n End-to-end Tests\u00a0<\/strong>are minimal\u2013sized suites\u00a0with\u00a0test scenarios concentrating on the major workflows and user journeys. The execution time is high as it may involve GUIs,\u00a0but the scope is limited.<\/p>\nWhy Do\u00a0You\u00a0Need a Special Strategy to Test Microservices?<\/h2>\n
The Microservices Testing Strategies<\/h3>\n
![\"\"](\"https:\/\/coforge.site\/cigniti\/blog\/wp-content\/uploads\/composition-1-555x197.png\")
<\/p>\nUnit Testing<\/h3>\n
Integration\u00a0Testing<\/h3>\n
Component Testing Microservices<\/h2>\n
\n
Contract Testing<\/h3>\n
\n
\n
End-to-end Testing<\/h3>\n
Performance Testing<\/h3>\n
\n
![\"\"](\"https:\/\/coforge.site\/cigniti\/blog\/wp-content\/uploads\/pyramid-1-533x300.png\")
<\/p>\nConclusion<\/h2>\n