jonfornari
jonfornari

Reputation: 520

Mocking a filter on unit tests of a flow in Mule

I have a flow that i want to test as follows:

<flow
    name="MyFlow"
    processingStrategy="synchronous">

    <all>
        <processor-chain>
            <and-filter>
                <filter ref="Filter1" />
                <filter ref="Filter2" />
                <filter ref="Filter3" />
            </and-filter>
            <!-- bla bla bla. doesnt matter for this question -->
        </processor-chain>
           <!-- more stuff that doesnt matter -->
    </all>
</flow>

Filters 1, 2 and 3 are all custom filters.

I'm having a problem with filter 2 since it got some integration code that i can't replicate or execute on a unit testing enviroment. It would be great to tell my test just to accept that filter no matter what.

I just tried something like this (my test class is extending FunctionalTestCase):

    muleContext.getRegistry().registerObject(
            "Filter2",
            new FilterThatJustAcceptsEverything());

But, that doesn't work.

Is there a way to mock that filter or some parts of its code just for this specific test?

This is how i'm calling it on my test method:

    flow = muleContext.getRegistry().lookupObject(
            "MyFlow");
    String content = "bananas";
    MuleEvent result = flow.process(getTestEvent(content));

Thanks in advance.

Upvotes: 1

Views: 571

Answers (1)

Ryan Carter
Ryan Carter

Reputation: 11606

For mocking, the best way is to use munit - https://github.com/mulesoft/munit

Where you can mock the filter to just return the same event so it appears it just passes through. Something similar to:

whenMessageProcessor("expression-filter").withAttributes(...).thenReturnSameEvent();

Or alternatively, if you want to use the standard FunctionalTestCase, I would suggest using side-by-side configurations - http://www.mulesoft.org/documentation/display/current/Using+Side-by-Side+Configuration+Files and providing stub configurations.

It already looks like your filters are global. So what you can do is place your filters in a separate configuration "filters.xml" for example and provide a "filters-stubs.xml" in your test case. Where they can just be generic filters that always return true like so:

<expression-filter expression="#[true]" name="Filter1" />

and in your test load the stub config instead:

 @Override
    protected String getConfigResources()
    {
        return "main.xml, filters-stubs.xml";
    }

Upvotes: 2

Related Questions