Pages

2012-05-08

My colleagues are definitely not very thrilled about me jumping on them asking for test-cases. "Automated testing" has been this thing hanging around in office for a while. But lately it took new form and status, with me trying to enforce it.

We always DID test our code. We did it in our own primitive ways. Dumping data-structures, assertions, tracing logs, running through debuggers, etc. But there was always these corners that showed up when run on the field. In our line of work, we dont have the luxury of testing our code against the actual machine. The machine is a freaking 50 feet long one. We get to do that shizzle only when we go to the field for deployment. And, having to fix silly uninitialized "shared_ptr"s, in a noisy textile mill that feels like an oven, is no fun at all. It gets all the more frustrating without office comforts like tables and chairs. Now, this could be the silliest case for the need of automated testing. But, it is one of the strongest cases for us at the moment: "Not having to fix trivial things at the field". NO, this post is not to make a case for "automated testing". There are better and more convincing reasons for it on the Internet.

We never thought we could make that code testable. It was an interconnected mess beyond compare. We had a singleton global-state holding all the objects. Any object that wanted to talk to another simply fetched it from this global-state. This seemed cool in the start. But, when more developers came in (and left), this global-state turned out to be a can of worms. There were so many redundant things which we could not touch because somewhere, someone was using it in an unusual way. After a painful refactor implementing "Dependency Injection (DI)" and a little "Pimpl", to a significant part of the code, things changed. Clarity happened. We realised that most of the issues we had were because of bad OOP practices. The process of implementing DI exposed a whole lot of GRASP issues. Fixing them, automatically brought down the complexity of the whole thing.

This whole 'refactor' thingy has cost us quite a bit. Our delivery got thrown behind by a couple of weeks. However, it has proven to be worthwhile. Bringing in DI enabled us to mock objects easily. Now we get to generate input patterns which can be seen only in the field, otherwise. Increased build times are a bit upsetting.

The point is, do not fear the 'refactor'. Its like the sadhana to reach Nirvana :)