Are you already using MUnits and Functional Testing within your CI/CD pipelines? If not, then you should! They are a great helping hand at building stable APIs. By running automated MUnit tests for new and existing features as part of Jenkins, issues are highlighted at an early stage. The same applies to functional monitor tests that are run post-deployment. These tests ensure that new changes have not impacted the general 'health' of the API.
Watch this episode to learn how high-level unit testing and functional monitoring testing can be used within a CI/CD pipeline. In our previous video, we looked into each of our Jenkins pipelines and showed the different stages within those pipelines. Our manual build and deploy pipeline had a stage where we ran MUnit tests against the code base and a further stage that triggered off a functional monitor test from within Anypoint Platform. In this video, we go into these in a bit more detail.
With our manual build and deploy, the Jenkins pipeline code is held in our BitBucket repository. If we go down to the Build & Test stage, we see that kicking off the MUnit process is a simple Maven command where the build and test are executed as a part of the 'package' phase. All we have to do is specify details of how to publish the MUnit test results.
A tip: Within this phase, you can set up Slack notifications. As soon as the MUnit tests have run, it will send a message with a summary of the results.
Once the pipeline has been executed, we receive a link to a quick summary of the Latest Test Results, which shows how long the specific MUnit tests have taken and which ones have passed. We also get a MUnit Coverage Report which shows us the code coverage we are capturing with our MUnit tests. As we go through we can see what the coverage is for each file and each flow.
Back on to BitBucket. The final stage of our pipeline is running a functional monitor test, which gets triggered after the API is deployed into CloudHub. This test ensures the quality and reliability of your API by validating its behaviour. MuleSoft Platform APIs can be used to trigger different actions, for example deploying APIs into CloudHub or kicking off a functional monitor test in Anypoint Platform. The latter I've covered in this video. It's pretty easy; all you need to do is specify which test you would like triggered with a specific version. When calling the platform APIs, you have to select other standard MuleSoft parameters such as organisation id and access token. These have all been configured in a properties file to make updating to newer versions and different organisations easier.
If we take a look at the Functional Monitoring section in Anypoint Platform, we can see our test that gets triggered off as part of the build. This test is straightforward as we are simply checking the HTTP response of an API call. But that's not all that these tests can do! You can expand the tests to suit the needs of the API itself to test its quality. We also show an example of a test where we make a few more assertions. This functional monitor is available via our MuleSoft Knowledge Base and can easily be migrated across to other organisations to get their Functional Monitoring started with a baseline.
Our monitor that gets triggered off from the CI/CD pipeline has also been triggered to send a Slack notification if any errors occur as part of running the test. This provides immediate feedback on the status of the API once it has been deployed and ensures the quality and reliability of the API is maintained.
What we go through in the video is a framework - something our clients can use as a starting point and further tailor it to their specific needs. These assets will help speed up the testing process and build stable and error-free APIs!