Consider the following command:
gradle -Dspring.profiles.active=production bootRun
If we start up the application issuing the preceding command and fire up the browser to the URL, http://localhost:8080/pi/123, we will get a fat error message on the browser screen. Ouch...
It says Internal Server Error, status=500 or something similar. That is because our code wants to connect to the backing services, but we do not have any yet. To have some to test the application on this level, we should create the backing services or at least something that mocks them. The easiest way is to use the soapUI program.
The soapUI is a Java program available from https://www.soapui.org/. There is an open source and free version of it, and there is a commercial version. For our purposes, the free version is enough. We can install it in the simplest click-forward way as it has a setup wizard. After that, we can start it up and use the graphical user interface.
We create a new test project, Catalog and inventory, and set up two REST mock services in it: Catalog and Inventory, as shown in the following screenshot:
We set up, for each of the mock services, requests to be matched and responses. The content of the response is text and can be typed into the text field on the user interface. It is important that we do not forget to set the media type of the response to application/json (the default is XML).
Before starting the services, we have to set the port numbers by clicking on the cogwheel to something that is available on the server. Since 8080 is used by the Tomcat server executed by Gradle, and 8082 is used by soapUI to list the mock services that are currently running, I set the catalog to listen on 8081 and inventory on 8083. You can also see these port numbers in the listing of the ProductInformationServiceUrlBuilder class.
The soapUI saves the project in an XML file, and it is available for you on GitHub in the project directory.
After starting the mock services, the error message disappears from the browser screen when we press refresh:
What we see is exactly what we typed into soapUI.
If now I change the inventory mock service to return 0 instead of 100, as in the original version, what I get is the following empty record:
{"id":"","title":"","description":"","size":[0.0,0.0,0.0],"weight":0.0}
The testing even on this level can be automated. Now, we were playing around using the browser and this is something nice. Somehow, I feel I am producing something when there is a program that is really doing something, when I can see that there is some response in the browser window. However, after a while, this becomes boring and testing manually that the application is still working is cumbersome. It is especially boring for those functions that were not changed. The fact is that they do change miraculously many times even when we do not touch the code that influences them. We touch the code that does influence the function except that we are not aware of it. Poor design, poor coding, or maybe we just forgot, but it happens. Regression test is inevitable.
Although browser testing user interfaces can also be automated, this time, we are having a REST service that we can test and that is what soapUI is for. We have already installed the tool, we have already started it, and we have some mock services running in it. The next thing is to add a New REST service from URI to the project and specify the URL, http://localhost:8080/pi/{id}, exactly the same way as we did for Spring:
When we have a REST service defined in the project, we can create a new Test Suite and a Test Case inside the suite. We can then add a step to the Test Case that will call the REST service using the parameter 123 if we modify the default value, which is the same as the name of the parameter, in this case, id. We can run the test step using the green triangle on the upper-left corner of the window, and since we have the tested application and the soapUI mock services running, we should get an answer in JSON. We have to select JSON on the response side; otherwise, soapUI tries to interpret the response as XML, and since we have a JSON response, it is not too fruitful. What we see is the following window:
It is the same response that we saw in the browser. There are no miracles when we program computers. Sometimes, we do not understand what happens, and some things are so complex that they seem to be a miracle, but they are actually not. There is an explanation for everything, it may just not be known to us. In this case, we certainly know what is happening, but why is it any better to see the JSON on the screen of soapUI than it is on the browser? The reason is that soapUI can execute assertions and in some cases, further test steps based on the result of the REST invocation, and the final result is a simple YES or NO. The test is OK, or it FAILS.
To add an assertion, click on the Assertions text on the lower-left corner of the window. As you can see in the preceding screenshot, I have already added one that compares the "title" field of the returned JSON with the text "Bar Stool". When we add the assertion, the default value it suggests is the one that was actually returned, which is just a very handy feature.
After this, running the whole test suite again will run all the test cases (we have only one), and all the test steps, one after the other (we again have only one), and finally it will display a green FINISHED bar on the UI, as shown in the following screenshot:
This is not all that soapUI can do. This is a well-developed test tool that has been in the market for many years. soapUI can test SOAP services and REST services, and it can handle JMS messages. You can create tests of many steps with these calls, loops, and assertions in calls or in separate tests, and in case all else fails, you can do just anything by creating programmed steps in the Groovy language or creating extensions in Java.