Disclaimer: This is a user generated content submitted by a member of the WriteUpCafe Community. The views and writings here reflect that of the author and not of WriteUpCafe. If you have any complaints regarding this post kindly report it to us.

In projects related to the development of microservice architecture, CI / CD moves from the category of a pleasant opportunity to the category of an urgent need. Automated testing is an integral part of continuous integration, a competent approach to which can give the team many pleasant evenings with family and friends. Otherwise, the project runs the risk of never being completed.

It is possible to cover the entire microservice code with unit tests with mock objects, but this only partially solves the problem and leaves a lot of questions and difficulties, especially when testing working with data. As always, the most acute ones are testing data consistency in a relational database, testing work with cloud services and incorrect assumptions when writing mock objects.

All this and a little more is solved by testing the whole microservice in a Docker container. The undoubted advantage for ensuring the validity of tests is that the same Docker images that go into production are subjected to tests.

The automation of this approach presents a number of problems, the solution of which will be described below:

concurrent task conflicts in the same docker host;

conflicts of identifiers in the database during test iterations;

waiting for microservices to be ready;

combining and outputting logs to external systems;

testing outgoing HTTP requests;

testing web sockets (using SignalR);

testing OAuth authentication and authorization.

It is the role of an IT Service Technician to help customers and consumers to understand how to fix their computers as well as other technologies.

Login

Welcome to WriteUpCafe Community

Join our community to engage with fellow bloggers and increase the visibility of your blog.
Join WriteUpCafe