We must avoid this, but can we? If we go back to look in our backpack (which I like to call testing toolbox) we find the functional tests or end-to-end tests. What does this mean? That we will only be able to detect that something has broken when the application crashes? Too late, don’t you think? But try something else… start the application and try to request the report for a user and a date from the application. You will see that the tests again work correctly in both the consumer and producer.
#Mockwebserver enqueue code#
Download the code and make the above modifications. Let’s see what some of those tests might look like.Ĭonsumer | ReportsServiceWithMockWebServerTest.javaĪnd perfect! the tests will continue to work on one component as well as the other.
#Mockwebserver enqueue full#
We have a backpack full of tools and resources that can help us to test each of these two components in a watertight way: unit tests, integration tests, parameterized tests, JUnit 5, TestContainers, Mockito, Pitest…įor example, in the consumer, we could test the services that include the calls to the REST API by mocking/stubbing the responses from the server. How would we test our application? What testing “tools” do we have at our disposal to test an application of this type?Īs we have said, the consumer remains a web application that accesses another application, which offers us its services through a REST API, the producer. Now let’s go back to what interests us: quality and testing. So far then, a little introduction or snapshot of the evolution of application architecture and a context to define some concepts that we will use throughout the article. This complete code, as well as the rest that we use in the different examples, is available at Github. The producer has an entry point for the URL /worklogs/worker/username?day=date and makes a database query to retrieve the user’s worklogs on a specific date and return them. Let’s see some possible code snippets of each: Having clarified these two concepts, we’ll make the most of using SERVICE to refer to each one of the functionalities offered by the producer. PRODUCER: With this term, we will refer to the REST API or equivalent service in its role of offering its functionality.CONSUMER: We will refer to the web application or equivalent service in its role of consuming another service.We are going to establish the terminology that we will use from here on: but to better understand the concept, instead of adding complexity, we are going to simplify it even more by zooming in on the previous image.Īs shown in the image, we have reduced the example to a web application that is responsible for making work log reports and that accesses a REST API to obtain information.
We could have more complex examples, where a service consumes another that in turn is consumed by a third party, etc. The 4 services would consume a common service in charge of the overall management of tasks and worklogs. We would have two applications (one for the generation of reports and another for managing tasks and worklogs) and both would have on one side their implementation of a web application and their mobile application. The example shown in the previous image is quite simple. The scheme of this said the service-based application could be reflected in the following scheme. Let’s imagine an application for managing worklogs, tasks, worklog reports…. 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.
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).
We have gone from having monolithic architectures to applications based on (micro) services. Application development has evolved, and therefore new needs have arisen when it comes to testing and new tools to deal with them.
0 kommentar(er)
