CODEWITHSUNDEEP
web-servicesmockingmule
Priya Gachinamath
Priya Gachinamath

Reputation: 115

Mocking services for integration testing in Mule

In our mule projects - we currently have our integration testcases call the actual external webservices (in house). This we obviously want to get rid of and have mock services for the external services, as we are almost done with setting up our build server for the mule projects.

I see that there are a lot of options available out there for mocking in mule flows:

  1. MuleSoft's Munit - which is still in Beta version; but supposedly the most suitable candidate. But since it is in Beta version could we go ahead and adopt it for our code which will soon go into production
  2. Confluex/Wiremock and a lot of other frameworks for mocking webservices
  3. Have testcases with an embedded jetty server to handle the request and mock the response.

Kindly let me know your inputs. Thanks and regards, Priya

Upvotes: 1

Views: 1284

Answers (3)

Ryan Hoegg
Ryan Hoegg

Reputation: 2475

I am one of the authors of confluex-mock-http, and am currently in the process of migrating the project to https://github.com/shamsoftware/sham-http . So, I am probably biased :)

I prefer to start an HTTP server in process, and that's why I helped build a project that does that. The library was made specifically because we had solved this problem several times using option 3. :)

I am about to spend some effort getting a release of sham-http out, and I plan to make it compatible with Mule 3.6.0. If you're using a different version, be sure to add an issue to make it compatible with whatever version you're using :)

Upvotes: 0

Mohan
Mohan

Reputation: 520

i feel it better to use munit xml configuration approach for testing mule flows.

you can mock the service, by specifying the required response to the mocking component for the web-service which is simple and preferable approach.For the mocking component you set the inbount properties like 'http.status'..etc ..respective properties which will be required in the next flow message processors.

Upvotes: 0

Dds
Dds

Reputation: 712

If you ask me I'll go with Munit, I understand that the BETA could be a little bit scary but:

  • Your test don't need as much stability as the production code
  • The BETA version of Munit is stable, i.e. it's not a snapshot so it won't suddenly change and brake your test
  • Munit will become GA during the next months

That's what regards to code stability. That said, Munit provide lots of other features besides of just mocking your flows, and at some point I reckon you may like not only to do unit testing of your mule application but integration test which you can also do with Munit.

Generally speaking your other options, while applicable, still relies in somewhat external systems while Munit is a native way to isolate your Mule code and avoid it from making external calls.

HTH

Upvotes: 2

Related Questions