If you are currently working on a project where several modules will have to communicate but they do not exist yet, then you may have to mock the communications.
And if you are using REST APIs, several tools might do the trick to provide a mocking server.
In the project I'm working on, we've chosen WireMock for several reasons — i.e. one standalone JAR, easy to integrate, easy to learn, etc.
The way we are using WireMock is based on a simple concept: writing JSON files containing some criteria to recognize a matching request and send the expected response directly.
Unfortunately, this involves a major disadvantage: redundancy. Let's look at an example. Say you have a test dataset with five customers. You want to:
Find all customers (one file)
Retrieve a customer from its code (five files plus one for not found)
Validate a customer code: "true" if it exists; "false" otherwise (two files)
You will need nine JSON files. And if you want filters for the search, then you're lost. If you want to change the name of the customer, you have to change two files.
You should see what I mean.
For urgent tests, I have typed more than 100 JSON files with consistent data. And I thought never again.
I searched for a solution to improve my day-to-day developing life with the following constraints:
Write data once and only once.
Adding data should be limited to adding data; no code.
It should be simple to add a new service mock using the existing data.
But found nothing in the existing WireMock extensions.
I thought about generating the result files from XML, CSV, etc. This would have been a bad idea. What if I add a new service allowing me to retrieve a customer from their mail? I would have to write new code for the generator. It would not be simple. And the filtering problem would still be unsolved.
You might be thinking, Dude, what you need is a database, and to code an app on top of it! Well...yes! Exactly! I need a database and SQL queries to retrieve data, and JSON responses generated directly and automatically from the SQL results. But I don't want to code an app each time I have to put up a mock server.
So the solution was to develop an extension to WireMock. This extension will perform the following:
Read data from CSV files with SQL as if it was a database but make it easier to deploy automatically with the mocks.
Extend the WireMock JSON files format to integrate the SQL in it. The SQL parameters will be the HTTP parameters.
The JSON responses will be generated automatically from SQL column names (or aliases).
Thus, the WireMockCSV extension was born. It has been enriched during the project with useful features, and now will handle:
Complex object hierarchy with objects lists, subobjects, sublists, etc. (Complex meaning with no limitation, but in general, it's not very complicated.)
Multiple SQL queries to build your response.
Some simple conditions.
Several options for personalization of the response.
Of course, there are no conflicts that WireMock can do normally. You can use all standard features in parallel even if you activate the extension.
It's open source, free to use, and free to distribute. Enjoy and save some time with it!