Another release, so soon?
Yes, believe it!
With MUnit 1.2.0, we launched Domain Support, and since then, we have been collecting feedback on the release. We take quality very seriously here – after all, we are a testing framework aimed at ensuring the quality of your code. With that in mind, we looked very carefully at what our users were saying and fixed every bug we could find.
Automatically test RAML-defined API
So, is it that all you guys did?
That’s a very good question, and the answer is no!
In this release, there are several improvements including the usability of the scaffolding feature in Anypoint Studio. For those that are new to this really cool feature, it enables MUnit to automatically generate tests for RAML files to test the RAML-defined API.
The way it works is very straightforward. You just right click on the APIKit Router and select the option Create ### Suite for RAML, and the feature will create a new MUnit Test Suite File with the tests:
Why so many tests?
We try to cover as many scenarios as possible for the defined API. For instance, let’s say you have a resource like this one below:
We generate a test for the GET method and another test for the POST method. Now this is a simple example, but what if the POST method also defined a 202 response code? In that case, we would generate another test to validate that. It can get even more complex if the definition could return different types of bodies in the response – for example, let’s say one response in a JSON format and another in plain text. In that case, we would have to generate tests to cover those scenarios as well. The cool thing is, the scaffolder feature takes care of all of this.
Full support for RAML 1.0
But wait, I thought you already had this, so what’s new?
Again a very good question (and fair, I may add).
For starters, we now provide full support for RAML 1.0. Additionally, we made other improvements based on feedback from our users, which you can see below.
What kind of “other” improvements?
For starters the Examples to Files
We used to take the examples from the RAML definition and use it as payload to send to the API or to compare responses returned by the API. The main problem was, it was hard to edit the complex examples. With this release, we added a feature that will extract those examples and placed them as files:
The files are mainly divided into two folders:
- scaffolder.request: for the examples related to request
- scaffolder.responses: for the examples related to the responses returned by the tested API.
To make it easy to identify which tests are associated with which file, the files are named after the associated test. They also have an extension, which can be either:
- json: for JSON-type examples
- xml: for XML-type examples
- txt: for the rest
In the tests, you’ll see that each file is referenced by a MEL expression such as:
#[getResource(‘scaffolder/response/get_200_notes_application_json.json’).asString()]
Now, for those of you who are nostalgic and loved the good old days where the really complex examples were mixed in with the Mule code, you can always disable this feature from Preferences by clicking on Create files for requests and responses:
And you call improvement to that small feature, nothing more?
Wow though public (and it wasn’t that small), but since you ask we also did UX Improvements
With the new release, you’ll notice that there is another preference there: Allow setting default values when scaffolding tests.
We noticed that the scaffolding process wasn’t very responsive. RAML is very versatile, and most things are not mandatory. While this is really cool, it can be challenging when you are trying to auto-generate as much code as possible. Since some of the fields were not mandatory, it also meant that the scaffolding process sometimes needed things that were not there.
To address this, the first thing we did is to improve the way we communicate the missing part of the RAML configuration. We did this by adding very specific messages when a required part for testing is missing. Please note that these are not mandatory parts of the RAML definition, and if they are not there, it is OK. But for testing, if they are there, it allows for a better understanding of the API and allows for more tests to be generated.
This new feature enables/disables these types of messages.
And what happens when these messages are disabled?
Wow, you guys are on fire with these questions…
In that case, MUnit scaffolding tries to get as smart as possible on its own. For instance, if you need to generate a payload to send to a POST request, the RAML definition is checked in the following order:
1. If there is an example, the example will be used.
2. If there is no example, but there is a schema (only for JSON types), the schema is parsed, and basic values are generated.
3. If none of the above, an empty payload is created.
If it comes to the last step, the user can, and should, update the test. We do something similar for query parameters and headers, so if no examples are provided, we first check for default values and if none are found, then we just place an empty string.
Also, for current users of MUnit, you will also notice that we’ve improved the scaffolding feature so that the code generation is based on far more elements than before. Additionally, we’ve also added support for traits.
We certainly hope you all enjoy this features and that it helps you test your RAML APIs as much as possible. But please remember people that scaffolding will only cover the basics — we encourage you to add additional tests or make modifications so that it addresses all of your specific needs.
Coverage updates
Wait, there is more!
We’ve added two more features unrelated to scaffolding. You can now opt out of running coverage when running your MUnit tests by just unclicking the option Run coverage in the launch configuration:
Also, based on the feedback we received about the context menus, we’ve added more options to ignore/enable tests:
We hope you find these new options useful.
On a final note, we heard that some of our Windows users were having trouble with MUnit. We took that feedback as well and tried to solve as many Windows-related bugs that we could find. So, if you are a Windows user, please take a look at this last release and give it a try. We want to hear your feedback!
For more information about the release, please check out our MUnit 1.2.1 release notes.
