Andrew's ramblings

Application development and testing your code

Tags: Test Driven Development, General, Coldfusion

Today I am going to touch on a subject that can all too importantly be overlooked, and regardless of whether it is open source or paid work there is an importance to releasing your code as bug free as you possibly can. I spent today trying to figure out why something that I had been using for a few years, had all of a sudden stopped working. I had patched this open source application to the newest version, which was about 5 versions ahead of what I was using.

When I began running a few tests on the patch before making it live, there was some very noticeable problems with the update. It just would no longer work in any way, and I noticed some very disturbing problems in the code that I had to ask the developer in question if they had done any testing on these changes. So without going into too much detail, I am going to use a few examples that will highlight the problem that I discovered in this case.

However before I do begin discussing this in more detail, I would also like to point out that Test Driven Development is all too important these days. And whether you are following the more adopted method of Unit Testing, or using your own approach it is important to test as much of your code as you can. Test Driven Development is about code coverage, and can highlight important changes that are made as either broken or not very quickly and very easily.

The problem that I faced was something that would have been picked up the moment it was first run, or at least given some basic test case scenario's in which neither appeared to have been made. My statement to this developer in asking if he could at least run some tests, was taken very offensively and politely said he would drop that support.

So what was the problem in this case, and why did it become an issue after I updated to the latest version?

The Application in question used an XML-RPC connection to the server to send packets of XML data across to the server, which then gave instructions on what to do from there. These packets also had embedded authentication credentials, that would be used to authenticate the process to make sure the request was made by someone who had the correct privileges.

So lets look at an example of what was happening and why it was not doing what it was supposed to do. A lot of unimportant code has been removed as it was not needed, the importance of the actual problem is what is important in this case.

Now the above code at first glance would not actually show any real problems, so lets be clear on what this is doing first and then I'll describe why this is a bug that was never tested.

As you can see from the code the XML-RPC contains the username and password, which is then later used to make sure there is an authentication done. Now the problem with the above code, is that there is a call to getData which is used to check to see if the data already exists and if it does then we will revert to edit mode. But the problem is that the code for getData has the following line of code in it.

So why is this a problem?

Well it becomes a problem because there is a check to see if the user belongs to the relevant role, because only the administrator can see anything that has been flagged as being in draft mode. So when we go back to the first code snippet, you will notice that the login code is after the call to check to see if we need to be in edit mode or new mode. So in this example if we just take the example above, the XML-RPC posted data would always be in new data mode and would never get into edit mode.

Now this wouldn't throw an error when the application is run, but it highlights that there is a bug in the code. Because if we do not test that we can also edit this data, then we will never know about the problem either and even though it would take just a few more seconds, it is important to run that test to see if it works as we intend it to work.

I wanted to write this post for a few reasons, one of those reasons is that the Application in question is open source. And I am afraid that just because it is open source, doesn't excuse the fact that there is a major bug in the logic in the above example and that the tests that would have picked this flaw in the logic were never run, and hence was never picked up.