In the previous post, we implemented a mule application that read a file from an inbox directory, processed its content and moved the file into an outbox directory.
In this post, we are going to write a unit test for that integration. Let's go!

Right click on the helloworld project and select new MUnit Test.
Select the flow that you are trying to unittest, set a name for the unit test and press Finish

Now you have an empty Unit Test for your flow that we are going to implement.

What can we test in this flow? Our application performs 3 main tasks:

• Read the file from the inbox directory
• Process the file content
• Move the file into the outbox directory

By testing task 2, we are effectively also testing task 1. After that, we can check that the file has effectively been moved into the outbox directory.
But before we get to writing the unit test, we need to modify the flow from the previous post. We had hardcoded the inbox path into the flow, which makes testing not flexible. We do not want to use the same path at runtime and at test time.
Let's create a global config and externalize the working directories.
Go back to the helloworld-flow and select the Global Elements tab

Edit the file_Config configuration and replace the hardcoded working directory path with the followingn placeholder parameter: ${file.helloworld.inboxDir}

Right click on src/main/resources and select new file. Give it the name config.yaml
Enter the lines:

file:
  helloworld:
    inboxDir: C:/dev/Mulesoft/tutorial

and save the file.

We need to tell Mule to read the newly created file to find the configured placeholder. We do this by creating a "Global configuration properties".
Go back to the tab Global Elements and click the Create button.
Under "Global configurations", select Configuration properties,

Press Ok and enter the name of the configuration file you created config.yaml

With that, we have externalized the path of the working directory and can use a different path in the unit test by using another property file only for the test. This is what we are going to do next:
Right Click src/test/resources and create a new File. Give it the name test-config.yaml.
In that file enter the following lines:

file:
  helloworld:
    inboxDir: src/test/resources/tutorial

This is going to be the working directory for our unit test.
In the Global Elements Tab of our unit test, add a new Configuration properties and set the file name to test-config.yaml. This way, MUnit is going to resolve placeholder properties by looking into that file.
To activate the file connector during test,
enter the following snippet under the <munit:test> tag in the configuration xml

      <munit:enable-flow-sources>
           <munit:enable-flow-source value="hello-worldFlow"/>
         </munit:enable-flow-sources>

or you can use the General Properties Tab of the test suite:

Here we enable the file connector, so that it can start polling the inbox directory during the unit test.
Now you can run your unit test. When it's done, you will get an error, because the directory tutorial is missing. Create 3 new directories tutorial, tutorial/inbox, tutorial/outbox

Now run you unit test and you will have a green line.
Sadly, we haven't really testes anything yet. We have just made sure that your testing environment is setup correclty.

Now we need to drop a file with a content into the inbox directory, and check the content in our unit test to make sure that the processor is working fine.
Let's configure a validation by adding an assertion to check the content of the file from tin inbox directory. We want to drop a file with the content "Hello World" in that directory.

Here we assert that the payload is equals to "Hello World". We have also added a logger in the unit test to be able to read the message in the console.
If you run this test, it will fail. Since we have enabled the file connector in the unit test, it is going to be running concurrently with MUnit itself on a different thread and MUnit will jump straight to the validation section of the unit test without waiting for the file connector to read from the directory. This is a tricky scenario, because the Unit Test should be synchronous with the event source in this case. A solution could be to disable the flow source in the unit test, and feed it a payload from another file connector.

Now what we need is to add a beforeTest processor to create a file into the inbox directory.

Now your unit test should go green.

THis is still not satisfactory, because the reference flow had to be disabled. The test.txt file stays in the inbox directory and is not being moved into the oubox directory.
In the next post, we will describe how to fix this issue so we can test a file connector without hacing to disable it in the unit test.
Stay tuned.