On The Nuclear Option With Regards To Test Driven Development

If you’ve been following me on Twitter, you’re aware of a little get-to-know-ya project I’ve been working on to learn Unity and Blender, called Monsta Punch!. You might have even played it (A/D: move; J: Quick punch; K: Heavy punch; SPACE: block — Note that I can’t guarantee that link will work forever).

Because Monsta Punch! exists solely for the sake of my own education, it has come along veeerrrrryyyy slowly as it frequently loses priority to reading and research. That priority reached the ultimate low point this week as I nuked the whole thing from orbit and started from scratch.

Psychotic!

It became evident to me while I was working on Fortress that I am an awful coder. More specifically, I’m a perfectly good programmer, but I’m a terrible software engineer. While I can make things happen on the screen, my code always has this kind of beautiful mind thing going on that makes it not only difficult but even disheartening to modify. This is actually the biggest reason why I cancelled Fortress: I couldn’t bear to work with its code any more.

Going into Monsta Punch!, I swore things would be different, and sure enough, things did not be different. Not 500 lines in, my Unity scripts began to spaghettify. Unacceptable. Something had to change.

I decided to spend the next two weeks doing nothing but reading. I started with the Gang of Four book, hoping for some insight into what I was doing wrong with respect to my architectural practices (I also picked up Programming Game AI By Example, mostly so I could take frequent breaks from reading about patterns). Turns out? My architecture actually wasn’t that bad. It had some suck, mind, but something else was wrong.

Changing gears, I grabbed Clean Code, which quickly proved to be my favorite textbook of 2011. So many wonderful insights that felt so obvious once I read them. If you are a coder, you must read this book.

The opening chapter of Clean Code made the briefest mention of test driven development. I dabbled with TDD a little bit in school (because I had to in order to complete the homework assignment), and randomly — thankfully — decided I wanted to know more about it. This led me to Noel Llopis’ series of blog posts on what TDD is all about and how to get started. My eyes were opened. Again, I encourage you to read up on the practice.

And so when I sat down with Unity again with a copy of Growing Object-Oriented Software, Guided by Tests looking up at me from my Kindle, the first thing I did was move my scripts elsewhere and start over. Now here I stand, the proud owner of a handful of tests that don’t do much yet, but I can already see that my code is more modular and readable. This is me hoping these last few weeks of non-productivity have paid off.