Friday, December 15, 2006
My current job involves working on an application that routes messages between a server and a bunch of terminals. When I first asked how they test this application during development, they told me the only way to test it was to hook it up to a server and a bunch of terminals.
"No, really, " I asked, "how do you test it?"
That really is what they do. They spend a few weeks writing code (without running it), then they go into "integration testing" where they hook everything up and see whether it works. Not surprisingly, their integration testing usually takes a long time, as many bugs are exposed and the application often needs significant rework to get it to function.
I told them that I'd like to have this stuff set up for me before the scheduled integration, so that I could test code as I made changes. "Sure, we'll get something set up for you next week," they said. They've told me that each week for the past six weeks.
The problem is that there are only a couple of people in the company who know how to set up the servers and terminals. Those people are swamped helping real customers; they don't have time to help mere developers set up systems that customers aren't paying for. And they don't have time to teach others or write down instructions.
So, I've spent the last few days refactoring the application so that I could run it without those external components. I developed mock objects to simulate the server and the terminals, so I can now run the application standalone on my laptop (or anyone else's laptop). I was told several times that it couldn't be done, but it really wasn't very difficult. That's a common pattern: people often think that mock objects and simulators are going to be impossible or too expensive to produce, but it usually only takes a few hours.
The biggest problem I had is that there is no documentation for the protocols used between my application and the external components. It took a lot of study and experimentation to figure out the specific ordering of messages that would make everything wake up and work correctly. I'm still not sure it is a perfect representation of the real system, which I still haven't seen, but it is enough to exercise the new code I've written.
They tell me they'd like me to re-implement the whole system over the next few months (after current crises are resolved). If I get to do that, testability is going to be one of the major features of the design. And "integration testing" will really be integration testing, not a replacement for unit testing.