Mastering MUnit: A Comprehensive Guide to MuleSoft Testing (Part – 2)

Recap

Take a peek at Part-1 of this blog at https://blogs.mulecraft.in/mastering-munit-a-comprehensive-guide-to-mulesoft-testing-part-1/.

MUnit mocking processors

The Mock When processor enables the imitation of an Event Processor based on specified conditions like its name and attributes. This functionality becomes crucial when validating various scenarios within a message processor.

For instance, consider a situation where a Mule application is under development and needs testing. If the database integrated into this application or the connector utilized within the message processor isn't prepared to handle incoming requests, testing becomes challenging. However, employing Mock When allows us to simulate the behaviour of the database connector in such scenarios. 

In essence, Mock When serves as a necessity when dealing with a database connector during testing. It allows us to create controlled conditions mimicking the behavior of the actual database connector, facilitating thorough testing even when the real system isn't accessible or ready to process requests. 

Flow will be like, 

The image displays a setup where a processor named db:select and an attribute called config-ref are specified, referring to the database configuration. To imitate or pretend to be the database functionality for testing purposes, a fake or test database payload is supplied within the value field. This dummy payload, retrieved from a specific folder location using MUnitTools, is compared with the actual database payload. 

When the test runs, the system checks if the dummy payload matches the real database payload. If they match, the Mock operation executes as intended. Essentially, this setup helps test the functionality by imitating the behaviour of the database without using the real database. 

 MUnit verify event processor 

The Verify Call allows us to verify if a processor was called. For example, we can validate if a specific processor has been called with a particular set of attributes for a specific number of times. 

When defining a verification, we are telling MUnit to fail a test if the verification is not successful. We can define verifications over any processor, even if we haven’t created a mock for it. 

Processor: This indicates which specific part of the system we're simulating. It's identified by a description in the format of {namespace}:{processor-name}. This can also use regular expressions for flexibility. 

Times: This parameter helps us ensure that the verification passes only if the specified processor has been called exactly N times. 

At least: This attribute ensures that the verification is successful if the specified processor has been called a minimum of N times. 

At most: This parameter ensures the verification is successful as long as the specified processor has been called a maximum of N times. 

Spy Event Processor 

The Spy Processor allows you to spy what happens before and after an event processor is called. 
This allows you to validate, for example that a selected Mule Event reaches a specific event processor containing a specific payload or variable. 

You can configure the spy processor to spy any Http Request and assert that the payload is null before reaching the component, and not null after it’s been processed.

 Spying on a component allows you to observe actions both before and after its execution, selecting the target component and defining criteria for identification. It's a way to closely monitor and record the behaviour of a specific part of a system before and after it performs its tasks. 

Or even to spy any Http Request, whose path is '/my/api'.

Within the spy processor, you have the capability to include elements like assertions, enabling observation of the system's condition or state. This empowers you to closely monitor and analyze the status of specific components within the system.

 As shown above, this processor allows you to define actions for before and after calling the spied processor.

However, keep in mind that the spy processor does not modify the original Mule Event.

If you set variables, attributes, or modify the payload inside a Spy, these changes won’t persist outside the processor. Overall, you should use the Spy processor to verify or assert. 

Bug-free API

In conclusion, MUnit's robust testing capabilities offer powerful tools like mocking processors, verifying event processors and spying events. These functionalities collectively empower developers to simulate, validate, and closely monitor specific components within Mule applications. Mocking processors allow for controlled simulations, verify event processors ensure expected behaviour and spy events enable precise observation without altering the original data.

Utilizing these features effectively streamlines testing, enhancing the reliability and accuracy of Mule application development while maintaining the integrity of the system under test.