A few of my fellow developers and I were recently tasked with bolstering the test suite which runs against our commercial framework. As I discussed in part two of The Summer of Bloated Software, HttpUnit, one of our shop’s favorite tools for testing, simply could not do the job due to the unusual way in which our commercial framework generated form fields. This meant that several important use cases could not be tested with HttpUnit, and that we were going to have to have someone manually test them.
First off, human unit tests are hard (without brainwashing) to automate, and secondly, the word manual is painful to any programmer’s ears – we are lazy and hate such exercises in brutish grunt work. We would rather write a script to do that grunt work for us.
Yet, poor HttpUnit, which is very script-like in its nature, was failing to meet our needs. This got me thinking. None of us wanted to do any manual work, so we could either write a patch for HttpUnit, use another HttpUnit-like framework, or write a new framework altogether. I immediately knew I did not want to write a patch for HttpUnit. Diving into someone else’s code takes time and patience, and at the moment I did not have a lot of either. So, I decided to start looking around the Internet for some HttpUnit-like alternatives. The first, and probably most readily available, replacement that I found was HtmlUnit, which uses the HTML document itself for performing unit tests, whereas HttpUnit makes use of the response. While I am certain that HtmlUnit’s approach has its merits, HttpUnit was nice and familiar, and I didn’t want to stray too far from it. I continued my searching but found nothing that looked promising. I was left with the final option. Write my own framework. (more…)
After reading about Retrospector’s recent adventures with Problogger.com, I figured I would go see what Problogger was all about. Right away I saw something that caught my eye: Wordpress themes! As it turns out, my own blog had been sitting around with the lame, smooth, pretty default Wordpress theme, which does not suit my art style or my personality AT ALL. Anyhow, I started browsing through some of the themes when I discovered Mars Spirit by B A Kahn. It had that dark, futuristic feel to it, which is very much a part of my own artwork. In fact, it actually reminded me of the Auriga interior from Alien Resurrection. Then all of a sudden I got to thinking what some of my artwork would look like plugged into the header, and I realized I had to give my blog a facelift. This is the result. I think you can all agree (at least those of you who know me personally) that this theme suits me much better! Oh, I almost forgot! The cropped image that I used in the header is a drawing I did during Christmas vacation my Freshman year in college. It is entitled Unrest, and it is one of my personal favorites. As always, stay tuned!
The debate over open source vs commercial software has had people flaming the forums for ages. It can be argued a million different ways, from a million different angles, by a million different zealots from either side. It is time I threw in my two cents. The inspiration for this portion of my post was derived from recent events. I have been entrenched for many weeks now working with a large commercial framework that powers a number of large, high traffic websites. This application in turn communicates with a webservice that was created using the open source Spring framework. Only recently, my efforts were redirected back to the webservice, which needed some refactoring for a new feature we wanted to implement. Working within the commercial framework and Spring is relatively complex from either perspective, and I would consider the two frameworks to be comparable as far as ease of use is concerned, with the commercial solution being marginally more complicated. However, in terms of testability, there is a clearly decisive winner: the Spring open source framework.
As a believer in test driven development, it is important that the code I’m writing to be reasonably easy to write tests for. The commercial software we use, however, has been built upon and built upon for several years, and in it predates the concept of test driven development. Its inability to remain flexible makes writing a unit test for it nearly impossible to do without using workarounds and hacks, which makes the lives of us developers hell. No decent coder wants to have to write hacks. For example, the commercial framework is notorious for generating drop-downs with non-unique names, making HttpUnit useless for page testing. Additionally, the way in which data is stored in the session makes it nearly impossible to write Cactus tests against it without using dirty, time consuming workarounds. This became painfully obvious to me while I was coding with Spring, which is not plagued by such problems. While I was working with Spring I had no trouble creating a useful set of test cases to run before deploying the application. If the commercial software were to be open sourced tomorrow, I am certain it would be vastly improved, since some of its more ridiculous flaws could be picked up and quickly repaired by the community. However, it seems that it is trapped in a parallel universe where modern practices no longer apply. In conclusion, score another point for open source. Its focus on standards and common, modern practices makes it vastly more testable than our bloated commercial software solution.
I have officially migrated my blog over to Wordpress. Unfortunately this means many of my old posts have disappeared, but I promise you there will be more to come. As always, stay tuned.