Contracting

I am about to end my first contract position with the Gila Community College Wellness Center in Arizona. I have been developing an internal web-based application for them and will deliver it at the end of this week. I was able to convince them to let me use Ruby on Rails for the development with a MySQL Database. Essentially these are the same technologies I have been using on my startup.

Have I mentioned recently that I love Ruby on Rails? No? Okay, ummm… I love it. For the startup I was concentrating on pushing features as quickly as possible and I was least concerned about formal testing. In a contract position though I needed to really delve into how to test my code using the built in functionality provided with Ruby on Rails. With a little help from the Agile Web Development with Rails book I was testing in no time. The testing framework in place makes it very easy to develop and run your tests. Eventually I will need to go back through my startup code and add tests. I was dreading that activity, but now it seems like it will be easier than I expected. Of course, I am a bad programmer for letting it lapse in the first place… baaaad programmer!

Testing is one of those activities that is often overlooked during the course of your academic career. When I completed my BS in Computer Science at the UofA testing was not on the curriculum. Our introduction to testing was when some teaching assistant developed a rudimentary suite of tests to grade our program. They usually released some of them so you could get a feel for how well you had coded, but your grade was based on a super-set of the tests you were given. Now that I look back on it they probably knew only a little more than us about testing, but of course they needed something to base a grade on. I remember several times when people discovered errors in the TA's tests!

There were very few people who developed their own tests. In fact, the philosophy I heard espoused most often from students and faculty was “Just get it working!” There was one guy though, Tal, who created tests and, compassionately, allowed others to test against them. He was a special case though as he was light years ahead of anyone else I knew in that program. Only later did I find out that he was a chess grandmaster... He eventually went on to pursue an advanced degree at UW and currently works at Google.

Anyway, I have wanted to try test-driven development for a while, but keep putting it off. Why? Why is it so hard to do? I think I have been conditioned to think of tests as a secondary activity. Sadly, this looks to be a difficult habit to overcome. Anyone have any suggestions for these testing withdrawal symptoms? Any advice is appreciated.

---

• ← Previous Post
• Next Post →

---