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

TDD of Python microservices

Formale Metadaten

Titel
TDD of Python microservices
Serientitel
Teil
151
Anzahl der Teile
169
Autor
Lizenz
CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
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.