Commonly missed web service tests

I've been developing web services for a few years now and noticed that better testing is usually needed when you are using web services because there are some aspects that are out of your control. Over the past few years, I have seen many issues arise from using web services that could have been fixed or mitigated with better testing. Some of the most common come from a combination of lazy coding and unexpected results. All of these issues can be fixed or handled in a way that users don't get the dreaded 500 error with a stack trace which won't do much for your user.

The great thing about web services is that you can change what happens behind the scenes without having to re-issue a library or jar file, but this means that sometimes the order of the response may change. I've seen a few developers hard code the parsing of the xml response instead of following the service spec. For example, there are times a developer will just assume the first node is what they are looking for but not check to see if it is the data they want. When a service gets updated it should always follow the spec but that does not mean the order is guaranteed to stay the same. If you are lazy and don't check what attribute you get back it can lead to some unintended consequences. It would be wise to add a unit or functional test that might return things in a different order just to see what kind of results you get.

Most of the time I bet your web service is fast, Lightning McQueen fast as my four year old says, and returns in under a second, but what if it hangs for say a minute or two. If you expect the response in less than a second what will your application do. Will it timeout, will it just sit there and be unresponsive, or might it crash? These types of things occur rarely but you should still have tests for it. Otherwise you don't know what will happen when it does occur.

Incomplete results is something else that could really throw a wrench into your application. Let's suppose that you make a call it returns just like you expect. You check the response code and everything is good to go but unfortunately you didn't get the entire response. What will your application do when it starts to parse the response. Most that I've seen throw up a horrible 500 error with a stack trace to the user. I know this might be helpful for you the developer but most users won't know what to do with it. A simple test can be added to keep this from happening and you'll be able to recover gracefully.

I know that none of these examples are earth shattering but it's surprising how often these cause problems for developers. Web services can make our lives as developers easier but if you don't test properly you might start to curse the web service when it is actually your fault for not testing better.

Programming Language Popularity

This recent post to the Spring Source team blog has some interesting statistics from two independent rankings of programming language popularity. BTI is continuously expanding our skills into the most cutting edge areas of the industry, as well as strengthening our existing expertise. Studies such as these are valuable to understanding the software development landscape.

Tour de Cure

Reston, VA- BTIer Paul Cugini will be cycling in the Tour de Cure on June 14, 2009 in Reston, VA to make a difference in the lives of 20.8 million Americans with diabetes. Tour de Cure is a series of fund-raising cycling events held in 40 states nationwide to benefit the American Diabetes Association. The Tour is a ride, not a race, with routes designed for everyone from the occasional rider to the experienced cyclist.

Please join BTI in supporting Paul on his ride: Paul's Personal Page

BTI is a fast growing software solutions company headquartered in Ashburn, VA. Founded in 2004, BTI provides Enterprise Service and Machine Translation integration solutions.