Blog: Generating MUnit tests using MuleSoft Dev Agent

Writing MUnit tests is something I do regularly as part of my MuleSoft development work, and like many engineers, I'm always looking for ways to work more efficiently without cutting corners. So when AI-powered features started making their way into the MuleSoft ecosystem, I was genuinely curious to see what they could do in practice. Test creation felt like the natural place to start, as it's a workflow I know well, which meant I could quickly spot where the tooling added value and where it still needed work.

One of those tools is the MuleSoft Dev Agent, which introduces a new way to create tests, using natural language prompts to generate MUnit tests directly from your MuleSoft projects. So in this walkthrough, we put the Dev Agent straight to work on a simple Hello World API and see how far it can take us, from generating MUnit tests in seconds to revealing where it really adds value.

For MuleSoft engineers interested in bringing AI-assisted tooling into their everyday workflows, this example offers a realistic view of how the Dev Agent performs today and what to watch for when using it in practice. Let’s get started!

What is the MuleSoft Dev Agent?

Built directly into Anypoint Code Builder, the MuleSoft Dev Agent acts as an AI-powered development companion, designed to support the entire MuleSoft application lifecycle. Often referred to as MuleSoft Vibes, it brings intelligent assistance directly into the tools developers already use.

Using natural language prompts, it allows you to perform the following actions:

• Develop API specifications
• Create and configure applications
• Create agent networks
• Search for assets
• Deploy and manage instances
• Secure your applications

The MuleSoft Dev Agent works by connecting to the MuleSoft MCP Server, which exposes a set of agentic tools that allow the agent to interact directly with your MuleSoft environment. Through this connection, the Dev Agent can read project files, generate assets, and carry out development tasks in context rather than in isolation.

Behind the scenes, these interactions are powered by large language models running within the Salesforce Shared Trust Boundary. This means the Dev Agent operates as part of the wider MuleSoft AI ecosystem, with security and platform controls built into how it accesses and uses your data.

How to access the MuleSoft Dev Agent

To get started with the Dev Agent, I followed these setup steps:

• Set up and access the web or desktop IDE
• Ensure you have the required Anypoint Code Builder permissions
• Verify that you have the following permissions enabled:
  • Anypoint Code Builder Developer (to use Dev Agent in the Cloud IDE)
  • MuleSoft Developer Generative AI User
• Make sure Einstein is enabled in Access Management

Once these steps are completed, the MuleSoft Dev Agent becomes available in Anypoint Code Builder in VS Code, and can be accessed by clicking the Dev Agent icon on the left-hand side.

On the bottom right, we can see two modes: Plan and Act.

In Plan mode, Agentforce gathers information to architect a plan. And in Act mode, Agentforce completes the task immediately.

Creating MUnit tests with MuleSoft Dev Agent

Before we begin interacting with the agent, let’s recap the Hello World project we’ll be working on. This is the same project used in previous blog posts in the series (you may want to check out the most recent one here).

It’s a simple API that exposes a single GET /hello-world endpoint. In the API implementation, we use only a Transform Message component, with the payload set to { "message": "Hello-World" }.

Now let’s look at how to create MUnit tests using the MuleSoft Dev Agent. Let’s enter the prompt “create MUnit test suite” and see what happens!

A lot will be happening behind the scenes. First, we can see the MuleSoft Dev Agent interpreting what we’ve asked it to do.

There will also be a series of pop-ups requesting Agentforce permission to read files, including the interface, implementation, and the pom.xml file. It will then add the required dependencies to the pom.xml file to create and run the MUnit tests.

Then it will use generate_munit tool on theMCP server:

The MuleSoft Dev Agent will start generating the code, and we will be able to see it being added on the right-hand side.

Then it will ask us to save the generated file.

Next, it will generate the test files for the implementation file. It will then verify that there are no errors, and if any are found, they will be corrected, as shown below:

Now let’s take a look at the generated tests. It will generate a single test per MuleSoft configuration file, each with a very similar implementation - it checks whether the message equals “Hello World” and that the payload is not empty.

Once the tests are generated MuleSoft Dev Agent will ask to run the tests.

It will also generate the report as below:

And that’s it for the happy path! Straightforward, isn’t it? Now let’s cover some error scenarios.

Creating MUnit test with error scenarios

I used the following prompt to write the error scenarios:

“Create a test case in the hello-world-int-test-suite.xml to check the console and HTTP listener, as well as error scenarios.”

Then it will use the generate_munit tool on the MCP server, as before, to generate the MUnit tests. In my case, the MuleSoft Dev Agent struggled to execute the tests and had to fix the errors it found multiple times.

Finally, the following tests were generated:

Here’s an example of the generated error scenario test. It mocks the APIKit and returns the error type APIKIT:NOT_FOUND. All the other error scenarios were generated in a similar way.

Then the MuleSoft Dev Agent ran the tests again. It also generated the following report but ran into an issue with the port being in use:

I have then asked to change the port to 8091 to fix the error. The tests were run again and the following report was generated, again with some errors, but MuleSoft Dev Agent highlighted that these are actually false positives:

I ran the test suites manually. As expected, there were many errors, but they were different from those in the report. This included the happy path scenario test - when generating the error case scenarios, the MuleSoft Dev Agent had modified the previously working happy path test.

Then I entered the prompt to fix the errors, but one error still remained:

Then it ran the tests, but we got an “API request failed” error. I tried to retry, but had to start a new task.

I created a new task to run the MUnit tests, which failed again. This time, it threw a different error.

It then proceeded to fix the broken MUnit tests, ran them again, and succeeded!

I have verified them again, by running them manually:

Key findings

After working through both happy path and error scenarios, a few consistent patterns emerged. While the Dev Agent can generate MUnit tests quickly, it often requires iteration and validation to get reliable results.

• Tests were frequently generated with errors, even for very simple scenarios.
• Some tasks failed with an “API request failed” message, requiring a new task to be started.
• The agent occasionally reported different issues when analysing the same file multiple times.
• Mocking was inconsistent, with the same component sometimes being mocked more than once.
• Some generated assertions did not align with the intended test behaviour.

In addition to these issues, longer or more complex tasks introduced further challenges:

• Sending multiple prompts within a single task often caused failures, meaning multiple tasks were needed to complete test generation.
• False positives appeared when running error scenarios for the first time.
• In some cases, the agent modified tests that were already working when new scenarios were added to the same file.

Practical recommendations

Based on these findings, a few practical approaches helped make working with the MuleSoft Dev Agent more predictable:

• Use multiple prompts to guide the agent rather than trying to achieve everything in one step. Iterating helps refine results and correct errors.
• Start a new task if the agent gets stuck or repeatedly produces the same errors. This often leads to better outcomes.
• Review all generated code carefully, as some scenarios and assertions may be invalid or unnecessary.
• Always run the MUnit tests manually to confirm results rather than relying solely on the generated reports.

Summary

The MuleSoft Dev Agent offers an interesting step forward in how AI-assisted development can support everyday MuleSoft work. Used thoughtfully, it can help accelerate common tasks like MUnit test creation, while still benefiting from developer oversight and validation.

As the tooling continues to mature, it’s worth experimenting with where it fits best in your own development workflows and how it complements existing practices.

If you’re exploring AI-assisted development in MuleSoft or want to talk through how tools like the Dev Agent could support your integration landscape, feel free to get in touch.

I for one am excited to see how this tool will evolve in the future, and of course, I will keep you informed of any updates you need to know about!