You probably heard we have been moving into a faster release cadence with the new mountain ranges releases in this post and this one. For many Product Managers or Business Owners releasing faster could be the difference between success and failure. Being able to shorten the cycle between an idea and valuable user feedback enables new companies to understand better market needs and improve based on it. Releasing valuable software earlier is the sweet spot for Agile and Lean methodologies.
Our integration tests should be portable, meaning that if we shared our project, everyone would be able to run our tests on any platform without needing to install any framework or application. This is a very common issue when we test flows that have an SFTP outbound endpoint. In order to do an integration test of our flow, we need to start an SFTP server on our machine or use a public SFTP server, which implies adding network overhead to our tests.
Testing using an external API can be a PITA, especially if the API uses any HTTP Callbacks or redirects such as OAuth or WebHooks. If your using any callback functionality like this then the Service Provider needs a way to callback your application and therefore be accessible to the public Internet.
When you start integrating these APIs, it’s much easier to work on your local development machine,
Most people who write UIs don’t care about testing. You know why? Because it’s hard. So hard, they’d rather not even bother and test things manually. You have multiple browsers. You have multiple platforms. And worse, you have all these frameworks and toolkits which are difficult to test. I’ll pick on GWT here for a moment. It takes 20 seconds to start a test – let alone a server side component to interact with or the time it takes to run your test.
Testing exception handling code is not always an easy task. You either need to setup the external conditions that cause the exception to be raised or generate mocks to get the same results.
A third option is using a bytecode injection tool like Byteman. Using Byteman scripting language you can insert custom behavior into the application code under test. The main use cases for Byteman are:
Automated testing using XUnit style frameworks can be achieved using several techniques. You can test a particular class, group of classes, or all your system at once. This selection will conform your SUT (system under test). You must define which technique or mix of techniques to use depending on your system and what best suits it.
In case you are trying to isolate your SUT form other components, such as collaborators, then you will need to create a “double”
Mule Management Console 3 ships with both mule2 and mule3 agents. You can monitor all your mule instances from latest MMC and benefit from UI improvements and bug fixes even if you didn’t upgrade to mule3.
MMC 3.1 takes it to another level by introducing backward compatibility support for both agents. Safely upgrades your MMC console without touching mule instances! Everything you already configured will still work and UI will provide access to features depending on agent capacities.
Over the years, I’ve seen many different testing styles while doing software development. Each one has unique characteristics, and some developers can identify themselves with more than one probably. I would like to go over all the different styles and point the effect it has over the project.
In part 2 of this mini-series I showed a flow that retrieves an RSS feed periodically, splits it and sends each RSS entry via email. In this part I’d like to show how to split up the flow a bit in order to enable unit testing.
To refresh your memory here’s what the flow currently looks like:
Testing this flow is hard if not impossible for a number of reasons:
Mule 3.1 introduces a very useful new <logger> element that makes it easy to inspect the content and properties of your messages in Mule while building or debugging a flow. It’s also perfect for logging errors, info messages etc. Mule has always supported logging with the <log-component> but while working with the new orchestration capabilities of Mule 3 flows, we found a real need for fine-grained logging. With the new message processor architecture,
