Most companies that use DevOps are turning to Microservices for their code development. Microservices are small-sized parts of an application that are focused on completing one task. They are a subpart of a module. These services are independent of each other. Hence they can be tested separately by QA testing companies without worrying about dependencies. Microservices can also be deployed independently.
All of those are neat benefits. But not everything is great when it comes to microservices. In fact, one of the downsides is that they are hard to test since each has its own codebase, dependencies management, and database schema. Even for local testing, you have to make sure that you’re using the latest code stack., all data migrations are up to date, and that you’re using the correct code branch.
Since this can be pretty challenging, here are a few ways through which microservices testing can be automated.
1. Full-stack inbox testing
In this, you create the testing environment on a local system. Then you carry out the quality testing on that local system, by testing each instance one by one. The machine is called a vagrant box, as Vagrant is used to creating that environment.
Benefits:
- Building your virtual machine will take minutes
- Pre-built Vagrant provisioners
- Anyone can test over the internet by downloading the same machine on their laptop.
- QA becomes easier.
Problems:
- Spinning the machine locally can have unexpected errors.
- This system doesn’t scale.
- Trying to replicate a cloud infrastructure environment on a local system doesn’t test the same way.
2. End to end testing
End-to-end testing is the Quality Assurance for all the parts of the system i,e, services, integration, interface, and network. This type of testing tests the whole user journey, from start to finish. You can also use the 80/20 rule – that is, not simulating all the parts of a real test, just pieces of it.
Benefits:
- It validates all layers of the service, such as the data layer, integration layer, presentation layer, and business layer.
- It reduces time and costs by decreasing errors.
Problems:
- Many companies don’t believe End-to-End testing is useful for microservices as they are not full applications. Hence there won’t be a workflow that tests all aspects of service.
- Testing gets complex every time you introduce a new microservice into the architecture.
3. Unit testing
Unit testing is done by writing test cases for a particular unit/part of the code. A unit can be one method or a whole module. The basic idea is to divide the repository into smaller components and to test them individually.
Ideally, unit testing should be done by minimizing external dependencies. Doing so will ensure quality even if the external environment around the unit changes.
Benefits :
- You can use different development languages or frameworks for unit testing.
Problems:
- Testers may write wrong tests
- Debugging unit tests often wastes time instead of saving it.
4. Documentation first testing
Also called the API First approach. In it, you create the API along with its documentation before anything else. The API documentation is made open-source.
Developers APIs are considered “High-level citizens.” Doing so creates a contract for how to make changes to them. If anyone wants to change API or create their own based on them, they’ll have to review the document to make sure that the new API upholds the standards mentioned in the Original API.
Benefits:
- Increases Speed to market
- It reduces costs. Well suited for cloud development.
- Many teams can work parallelly based on API definitions in the documentation.
Problems :
- Setting up the initial API can be challenging.
- Testing all parameters in API Request combinations can take long
- Schema updating of the API may cause downtime because of new parameters.
5. Stubbed Testing
Used for top-down integrating quality testing. In it, you use small codes called stubs for testing. They behave and handle data like microservices but they are just dummies – small, isolated parts of your application.
Software testing companies use stub tests when they need to do QA after taking input from the user. The system can just mimic user behavior.
Benefits:
- Can test the primary module without the smaller modules (top-down approach)
- Reproduce complex modules easily
- Can test without the required response.
- Saves time
Problems:
- Shallower than other methods.
- Static methods cannot be stubbed
- Pointer method signatures not supported.
You can use different tools software testing companies use to test microservices, such as:
- Goreplay: Open-source, a networking tool that monitors live traffic.
- VCR: a unit testing tool that records HTTP interactions for your test suite.
- Apiary: a documentation tool. It can write, mock, and spin an API in 30 minutes.
- Wilma: Service virtualization tool. Combines Service stubs and HTTPS proxy
- Wiremock: HTTP based API simulator. Creates an actual HTTP server and mimics web service.
Conclusion
Microservices testing can be difficult but is an unavoidable part of development. You can change your strategy as per requirement and situation. There is uncertainty in this type of testing, but if you apply tried and tested theories like Stubbed testing, documentation testing, etc., you won’t face any problems.
