The “Man-in-the-Middle” attack is such a well-recognized security risk, with established solutions and preventative measures in place that when I first heard about the recent ruckus around the Apple security flaw, I thought Apple’s trouble was more legal in natural, maybe some sort of royalties dispute between iTunes and the Michael Jackson estate. Only later did I found out what all the fuss was about “in the middle”, not “in the mirror”, and why I had to upgrade the iOS on my iPhone on a beautiful Saturday afternoon.
Regarding the specifics to Apple’s security flaw, there is already plenty of press coverage out there. For example, David Auerbach wrote a great analysis over at Slate.com.
In this post, I’d like to illustrate how automated unit testing with appropriate code coverage could have detected that particular kind of error, the one caused by grammatically correct code that inadvertently invalidated the whole logic of the program. We will build the unit tests using the MUnit module, an open source Mule testing framework that significantly streamline and simplify the process of writing unit tests.
We have built a simple, demonstrative application that processes incoming messages differently depending on whether a property of the payload, called “goodguy”, has value of “true” or not. If the value was true, the message would be processed one way and an HTTP 200 status would be returned. If it was not, the message would be processed another way and an HTTP status 400 would be returned:
The key logic for routing the message is shown below:
Let’s assume the initial release of the application had passed manual end-to-end testing and UAT and had been deployed to production:
Now let’s pretend that over time, additional features had to be added to the application so the code had to be touched again, and a developer had accidentally changed the double “==” to just a single “=” in the expression in the Choice router. If there was no unit testing, the application would package successfully, deployment would go smoothly, and the application would actually run, but just not processing the messages correctly:
The application would have failed during the build phase and would never have been deployed to production, as illustrated in the screenshot below. Note that maven displayed how many tests were, how many failed, and the reasons of the failures:
Note that the unit tests covered both the “happy path” and the “sad path” to achieve sufficient code coverage. If the code covered by the unit tests were sparse, erroneous lines could still slip in and remain undetected.
Hopefully this explains the title of this blog entry and it all makes sense now. If not, WTF is the most used abbreviation in the tech industry anyway, and the best part about WTF is that you can sprinkle it all over your code comments, and no amount of automated unit testing will ever catch it.