We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

TDD of Python microservices

Formal Metadata

Title
TDD of Python microservices
Title of Series
Part Number
151
Number of Parts
169
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Michał Bultrowicz - TDD of Python microservices A framework-agnostic approach to creating Python microservices with a tests-first approach. I'll show how to utilize Docker and Swagger to create service and contract tests that run your service as an independent process, as if it was running in production, giving you and your team a higher degree of confidence when introducing changes. A little bit of a broader microservice, TDD and work management context will also be given. ----- These will be my ideas on how to help a microservice-based (HTTP) project by integrating testing into the development process (TDD). I'll approach the testing pyramid presented in Martin Fowler's "Microservice Testing" as well as the test variants in "Building Microservices" (O'Reilly) and I'll show a way of how they can be translated to real-life Python. The main focus will be on "service tests" (aka. out-of-process component tests) and contract tests. They both can be run relatively fast on a development machine and can give fast feedback to the developer, preventing many kinds of problems. Service tests run the whole application process without any internal modifications, but have to present the service with a fake "outside world". I'll show how to fake external HTTP services with Mountebank (similar to WireMock). Instead of faking other systems (like databases) we can quickly spin up the real deal as a Docker container from within the tests. Contract tests check if the contract (interface) of your service with the outside world is kept, so no external services should be broken by the changes you are introducing. It can also work the other way around, proving that your collaborators are keeping their part of the deal. In both cases, Swagger (a RESTful API description scheme) and a few clever tricks can be used for significant advantage.