# Generating MUnit Tests for MuleSoft APIs with CurieTech AI | Test Coverage (Part 4)

> Use CurieTech AI's MUnit Test Generator to create passing tests for each flow, then merge the pull requests and push coverage toward 100%.

- **Watch:** https://www.youtube.com/watch?v=79x16XivYXQ
- **Page:** https://prostdev.com/video/generate-munit-tests-mulesoft-curietech-ai
- **Series:** From Zero to API with MuleSoft, CurieTech AI & Anypoint Code Builder (2025)
- **Duration:** 19:39

## About this video

Use CurieTech AI's MUnit Test Generator to create passing tests for each flow, then merge the pull requests and push coverage toward 100%.

## Resources

- [GitHub repo — todo-app-mule-curietechai](https://github.com/alexandramartinez/todo-app-mule-curietechai)

## Transcript

### Recap and what's next

Hello everyone, my name is Alex. Welcome back to our awesome CurieTech AI playlist. In the last
video we got our final Mule application — the To-Do Task Management app — fully working: get all
tasks, create a new task (with the auto-generated id), get a task by ID, update a task by ID, and
delete a task by ID.

The next step is to create MUnits — and nope, we won't be creating them on our own. We'll rely on
CurieTech AI. In CurieTech's **Testing** section there's an **MUnit Test Generator** and a
**Sample Data Generator**. We'll select **MUnit → Start my own**.

That reminds me: I merged the pull request CurieTech created before (the `curietech-dev` branch,
"implement to-do API CRUD") that we used to push all our fixes. So everything we have now is on
the `main` branch.

### Configuring the MUnit Test Generator

In the MUnit Test Generator, select the repo, the branch (`main`), no VM args, enable coverage,
and set "make as many scenarios as needed." Note the **number of MUnit scenarios: at most 3**. You
can lower it to 1, but this is the *maximum* it can generate — it looks at your code and decides
how many scenarios it needs, up to that max.

It's very important to provide your settings.xml, because you might need access to your RAML or
OAS (my case) and your Nexus credentials. If you don't know how to set up Nexus credentials, I
have a few videos on that.

Now the fun part: **you have to select just one flow** — it generates everything for one flow at a
time. We have main, console, and the five resources (delete, get all tasks, get task by ID, create
new task, update task by ID). We'll go one by one through the five, since those are the most
important. Select **delete** and submit; add a new task, select **get** (the list), then the other
**get** (by ID), and so on for all five. The cool thing is you can have them all running at the
same time, which is what I did — and because we're using a GitHub repo, it creates a **pull request
for each one** as soon as it's done.

### Reviewing the generated scenarios

Take the PUT (update). We didn't add a description, so it only used the flow name. It shows what
it's doing:

- **Scenario 1** — successfully update an existing task (the happy path), mocking the database
  connectors, running the target flow, and asserting the logger is called and the DB connectors
  are called as expected.
- **Scenario 2** — attempt to update a task that does not exist (the 404 path).

For the POST (create), it generated only **Scenario 1** — the happy path. For get-by-ID, two
scenarios (retrieve a task, and task not found). For get-all-tasks, just one scenario (the happy
path). For delete, two scenarios (successful delete, and task not found).

Some flows got only one scenario because it's just trying to cover 100% — and it decided one was
enough. But as you and I know, **100% coverage doesn't mean the tests are correct**. If you want
more scenarios — for example, get-all-tasks when there are zero tasks, or a database connection
failure — you can add them in the optional **notes** when you select the flow. Just remember it
creates at most three.

When a flow finishes, you get a summary: it created the tests, both passed, plus the MUnit coverage
report. Overall application coverage shows low (e.g. ~23%) because you're only doing one flow at a
time. The report has a table of every flow and its coverage percentage — the PUT shows 100%, and so
do the rest, including the get-all-tasks that only had one scenario (which is why it decided not to
create more).

### Merging the pull requests

In my GitHub repo, the five pull requests were added correctly. We can go branch by branch, but
let's just merge them. Take get-tasks-by-ID: it has the full summary, the coverage report, and the
two scenarios. Merge it, confirm, and delete the branch. Looking at the files, it added everything
needed to the `pom.xml` for MUnit, the flow, and some expected-response JSON files so it can mock
responses and assert expected vs. actual.

For the PUT, the files include the pom, the flows, and mock data for scenario 0 and scenario 1 — so
it's even testing an empty scenario. Now we have a **conflict** because it modified the pom. Open
that branch, and by pressing `.` on the keyboard we can spin up the VS Code web editor and rename
files. I want to keep them separate, so I'll rename the test suite XML and its resources folder to
include "put," and rename the config name as well. Commit and push, refresh the PR — now there are
two commits taking my changes, and it merges without conflict. Delete the branch.

I'll also rename things on `main`: press `.`, rename the get-by-ID flow and do a replace, and
remember to also rename the folder inside the resources folder (I forgot the first time and had to
come back). Merge, push, and continue with the rest of the PRs. Once there are no open PRs left,
click **Sync changes** to pull everything down. The git graph is funny — merge PR, then CurieTech 1
through 5 with all the renames.

### Renaming the test cases

Another issue: all the MUnit tests have the same name, like `flow-test-0`. So I'll rename them by
their scenario. For the delete suite, one is the happy path and one is "task not found," so I'll
name them accordingly. Do the same for the others. Now in the **Testing** section we can see all
the flows as test suites, and opening one shows how many tests each has — "happy path" and "task
not found" — which is awesome. Now we can run them all.

### Final coverage

I've been having an issue running the tests in my ACB — that's a *me* issue, not a CurieTech or
MuleSoft one; I should probably reinstall everything. But since all my credentials are in my
settings.xml in my `.m2` directory, I can just run everything with **Maven** instead.

After it finishes, the new coverage is **83.93%**, because it's not covering the main and console
flows. The summary table shows main at 0% and the API console at 0%. I don't really need the API
console — deleting it was a best practice in some previous projects — so let's delete it and run
again. Now we're at **87.04%**.

To get the rest, we'd need MUnits for the error scenarios in the main flow (it's just doing the
routing, plus error propagation / error handling for things like APIkit BAD_REQUEST and
NOT_FOUND). There are about six of those, so you'd create two CurieTech tasks (three scenarios
each) telling it exactly which errors to trigger. I'll leave reaching 100% as your **homework** —
send me your results on LinkedIn, Discord, or alexpros.com and I'm happy to take a look.

### A reminder about automating the manual steps

Quick reminder: everything I did manually (renaming, merging) I didn't *have* to do manually — I
just found it easier to show you once. There are a few ways to automate it with CurieTech:

1. Add **notes** when you create each task, specifying your naming conventions for test suites,
   folders, etc.
2. Go to **Settings → Workspace** and upload a PDF with your coding guidelines, e.g. "make sure all
   test suites and folders under src/test/resources match the test suite name and are descriptive."
3. Use the **Code Enhancer** afterward to ask it to rename all of those things.

### Wrapping up

So we already have a functioning application: we created an API specification on day one, debugged
and implemented it in videos two and three, and now in this fourth video we're creating MUnits to
get almost 100% coverage. Isn't this awesome? Let me know in the comments what else you'd like to
see. See you in the next video. Bye!