The first step we've decided to take to ensure that behavior is maintained during refactoring is to write end-to-end tests. In other applications that include frontends, this could be using a higher-level tool, such as Selenium/Selenide.
In our case, as the frontend is not subject to refactoring, the tool can be lower-level. We have chosen to write HTTP requests for the purpose of end-to-end tests.
These requests should be automatic and testable, and should follow all existing rules for automatic tests or specifications. As we were discovering the real application behavior while writing these tests, we have decided to write a spike in a tool called Postman.
The product website is here: https://www.getpostman.com/. This is also possible with a tool called curl (http://curl.haxx.se/).
curl is a command-line tool and library for transferring data with URL syntax, supporting [...] HTTP, HTTPS, [...], HTTP POST, HTTP PUT, and [...].
What's curl used for?
curl is used in command lines or scripts to transfer data.
Source: http://curl.haxx.se/.
To do this, we decide to execute the legacy software locally with the following line:
./gradlew clean jettyRun
This fires up a local jetty server that processes requests. The big benefit is that deployment is done automatically and there is no need to package everything and manually deploy to an application server (for example, JBoss AS, GlassFish, Geronimo, and TomEE). This can greatly speed up the process of making changes and seeing the effects, therefore decreasing the feedback lead time. Later on, we will start the server programmatically from Java code.
We start looking for functionalities. As we discovered earlier that the BooksEndpoint class contains the webservice endpoint definitions, this is a good place to start looking for functionalities. They are listed as follows:
- Add a new book
- List all the books
- Search for books by ID, by author, by title, and by status
- Prepare this book to be rented
- Rent this book
- Censor this book
- Uncensor the book
We launch the server manually and start writing requests:
These tests seem good enough for a spike. One thing that we have realized is that each response contains a timestamp, so this makes our automation more difficult:
For the tests to have more value, they should be automated and exhaustive. For the moment, they are not, so we consider them spikes. They will be automated in the future.
In this particular case, we have found that the Postman tests are a better investment because, even after writing them, we will throw them away. They give very rapid feedback on the API and results. We also use this tool for prototyping the REST APIs, as its tools are both effective and useful.
The general idea here is this: depending on whether you want to save those tests for the future or not, use one tool or another. This also depends on how often you want to execute them, and in which environment.
After writing down all the requests, these are the states that we have found in the application, represented by a state diagram:
After these tests are ready and we start to understand the application, it is time to automate the tests. After all, if they are not automated, we don't really feel confident enough for refactoring.