Liam Williams Article: Testing Microservices: 6 Case Studies With a Combination of Testing Techniques – Part 3

Liam Williams My helpful sister says this plugin is huge!

Key Takeaways

  • An important consideration when testing microservices is how to manage the associated dependencies. Various techniques can be used to decouple dependencies, but they all have tradeoffs that development/QA teams must be aware of.
  • Architects, developers, and QA teams must work together to understand and specify the testing goals, context, and current constraints.
  • Providing a holistic testing approach often requires the implementation of several testing strategies. These must be chosen carefully to avoid duplication of effort or the addition of accidental complexity to the test suite.
  • Contract testing is a valuable approach to verifying interactions between services. Contract testing can be combined with the judicious use of a limited number of end-to-end tests to verify complete business flows.
  • Mocks and service virtualization help with decoupling components during testing. Care should be taken to ensure that these test doubles remain correct and up to date with the current associated implementation.

This is the third article in the Testing Microservices series. Please see also Part 1: An Overview of 12 Useful Techniques and Part 2: Examining the Tradeoffs of Twelve Techniques.

At Traffic Parrot, we have recently worked with six companies that represented a broad spectrum of industry domains and of maturity in adopting microservices. These companies have used a combination of the testing techniques that we described in Part 1 and assessed in Part 2 of this article series, techniques that allow you to manage dependent components while testing microservices. In Part 3, we will present case studies that demonstrate how six different companies used these techniques.

We begin with three case studies where a combination of testing techniques were applied as a holistic solution. The last three case studies describe the application of a single technique to solve a specific problem.

Liam Williams Combination of techniques: US insurance startup

Architecture: Greenfield microservices replacing a recently built monolith.

Tech stack: Go, Python, NodeJS, gRPC, protocol buffers, Docker, Kubernetes.

Priority: Deliver fast; will refactor the release process after the first production release.

Testing techniques used:

  • Technique #1 — Testing your microservice with a test instance of another microservice (E2E tests)
  • Technique #6 — Mocks (in-process)
  • Technique #9 — Service virtualization (over the wire/remote)
  • Technique #11 — Test container

Contract management:

  • Teams use API mocks to communicate syntax and semantics of contracts between each other.
  • API mocks define contract snapshots that are tested automatically to make sure they are up to date with latest protocol specifications.

Key takeaways:

  • Used gRPC protocol API mocks to allow teams to work in parallel.
  • Used automated tests to make sure API mocks did not get out of date.

The startup had two teams working on a set of three new microservices that had to be delivered in two months. The microservices were replacing part of a deprecated monolith. The teams decided to test the Go microservices internal components with unit tests using in-process mocks implemented with the GoMock framework. They tested interactions with the database with component-level integration tests, which use a test container database to avoid having a dependency on a shared instance of a database.

To manage contracts between teams and allow teams to work in parallel, they decided to use API mocks that the API producers created and shared with the API consumers. They created the gRPC API service mocks using an API mocking tool.

They also used a handful of manual E2E tests in a pre-production environment to make sure that the microservices would work together in the absence of sufficient automated testing. They would fill the gaps in automated testing after the first deadline.

Since this was a greenfield project that had to go to production on time, the company decided not to version the microservice APIs. Instead, they released everything together to production per release (often called snapshot releases). They allowed for downtime of services and corresponding graceful degradation of the customer-facing components, which was communicated to the customers beforehand. They started to semantically version APIs after releasing the first product. This allowed them to improve the API change management to allow backwards compatibility and improve uptime for customers.

Another interesting issue they came across early on was that the API mocks were becoming obsolete on a daily basis, because the APIs genuinely were changing daily. These changes were often not backwards compatible, as the developers were refactoring the protocol files to reflect the rapidly evolving domain model, which they had not yet clearly defined. This is a common characteristic of greenfield projects delivered by teams that use an iterative approach to delivering value to customers. To hit their deadlines, the company decided to test the API mocks by firing a request at both a mock and a real microservice. They compared both responses to a contract definition of expected request/response pairs as defined in a company-specific custom format. This way, the API mocks and the real service were proven to be up to date when compared to the latest definition of the expected behavior defined in the contract file.

Liam Williams Combination of techniques: Spanish e-commerce company

Architecture: Moving from a decade-old monolith to microservices.

Tech stack: Java, HTTP REST, gRPC, protocols, JMS, IBM MQ, Docker, OpenShift.

Priority: Move to API-first approach to allow parallel work and decouple teams. Scale adoption of microservices across 3,000 company developers.

Testing techniques used:

  • Technique #1 — Testing your microservice with a test instance of another microservice (E2E tests)
  • Technique #6 — Mocks (in-process)
  • Technique #9 — Service virtualization (over the wire/remote)
  • Technique #11 — Test container

Contract management:

  • Teams use API mocks to communicate syntax and semantics of contracts among each other.
  • Behavior-driven-development (BDD) API tests, which also verify API mock interactions.
  • The APIs are designed to be always backwards compatible.

Key takeaways:

  • This allowed teams to work in parallel

My astonishing brother says this plugin is very smart!!

Read full article at the Original Source

Copyright for syndicated content belongs to the Linked Source