Ok. Face the music. Let’s debug.
Check list:
What is happening here?
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:
When your test base can be measured in tens of tests (or more) you should pay attention to bests practices and design principles if you want a highly maintainable code, quite resistant to technological changes, changes on the UI, etc. This article introduces Page Model pattern that is a great help in that regard.
Why are GUI integration tests needed? On which testing tool technology should I base my tests? What are the cost/benefit of the choosing one over the other? In this brief article we will give you a quick look at the answers to those questions.
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,
