Posted on

Testcontainers: Containers for Testing

I’ve always been more of a fan of unit tests than integration tests, mainly for one reason: I don’t need anything external to be able to run them. I don’t need to have a database started, an external service to connect to, or a Kafka running to be able to run the tests and therefore to be able to develop. 

That’s in the development environment, but if we’re talking about the integration environment, then I won’t even start. For example, in the case of databases, we have the option of doing the tests with H2. But it is also true that depending on the type of project, it could be that something which works perfectly in H2 does not work in the database for which we are developing: As sure as we have often relied on:

Posted on

Playing With Spring Cloud Contract

In a previous post, we saw how new needs arose in the field of testing derived from the evolution of application architectures.

Through a simple example, we established concepts such as consumer, producer, and service and showed that just as important as testing the functionalities in consumer and producer independently is, so also is ensuring that the interaction between them both is right.

Posted on

Introduction to Contract Testing, Setting the Context

Application development has evolved, and therefore new needs have arisen when it comes to testing and new tools to deal with them. Let’s take a look!

We have gone from having monolithic architectures to applications based on (micro) services. Why do I say (micro) services instead of microservices? Because although the literature talks about the evolution of development from monolithic applications to applications based on microservices, in reality, we often find ourselves with the integration of services (as is, without the need for them to be micro). The concept at hand applies equally well to the concept of microservices as it does to services, so from here on we will simplify using the term services.