Test Driven Design

So these days, I’ve started to put together a platform for some work at work. Something involving timing and scheduling. (Yay for woefully underdescript descriptions of what I’m doing). Now of course, the interesting tidbit about this is not the software itself, as code is code, and end the end, there are many end products. The cool part is the design process and architecture. And for me, this means a first venture into TDD(Test Driven Design).

On my own, without any outside suggestion to do so, I am experimenting with TDD for this project. Making it clear this is fully my idea and experiment. Though why would I want to do such a thing to myself? Why would I want to decree myself, and cast myself into the world of unit tests? It turns out, that this is suppose to be a platform type piece, so in the back of my head, when I started drawing out a design on paper, my thoughts traveled to how hard is this going to be to maintain down the line. After all, I am just one code monkey type person, and one person can only do soo much if all he does it sit around and fix bugs on his prior projects.  This more or less lead me down the thought-path of I should most likely make some sort of attempt to validate what I’m doing. Make sure I’m doing it right. And make sure that when I change something, it doesn’t break everything.

And this is renforced by my choice of language. The first draft for the first class was done in scala. But as one of my co-workers put it, I more or less got fed up with scala’s functional nature, its desire to hate mutable objects. So I rebeled. Hard. Into the most mutable language I could find. So this quickly became a javascript/node.js project. The only downside to node in my option though is the fact that node has no constants. So the only way to have personal guarantees of functionality is to make unit tests for them. Ruby, another dynamic language, also has a similar philosophy in development to my knowledge. For testing platform, I’m using mocha and chai.

So we set out to write code, and write unit tests for code. Of course, comming from a… code of the top of your head mentality I suppose. Actually have no idea what you’d call my development style, I attempted to incorperate into it some unit tests.

To start with, I wrote a function, then I wrote some tests for that function. It was good. made me feel a hair more certain that my function actually worked. Then I thought up what I wanted to do next. wrote some skeleton code, wrote some tests. Then went back in to making all the unit tests pass mode.

Today, I hit a new mark. coded the unit tests first. Never done that before. So lets see where this monstrosity is headed…

Leave a Reply

Your email address will not be published. Required fields are marked *