Koolaborate's Blog

This is a rewrite of my previous blog on test driven development, or TDD.  It will be based on two premises.  First, all tests (including test files) are going to be in Java.  That means we will be familiar with the language, understanding of the Eclipse IDE and know something about JUnit.  For those familiar with other languages, this blog may or may not seem fit.

Second, we will solve problems form Project Euler by writing tests first.  I’m not through the problems, not even close.  I’m not even sure if this process can scale (adjusted for my problem solving skills) as the problems get harder.  But I will try to solve as many as I can.

That being said, I would like to introduce some best practices into how we should break these problems down.  First, let’s make the code work under 60 seconds.  If the code doesn’t work, we can’t solve the problem, right?  Second, make the code elegant.  Third, make the code fast.  The second and third are a little tricky.  We aren’t working with a complex business process.  We are working with algorithms that’s been studied and has been around for a while.

So when you solve a problem in Project Euler, you get to see the answer which may be different from what you wrote.  You may notice it’s a lot smaller and is more efficient.  By reading the solution, I have learned a lot.  Perhaps the next iteration of these problems will focus on code optimization after writing the initial solution.

A computer science approach is to think about the problem, and write the most optimized code.  Elegance and speed are paramount.  I don’t disagree, however, with TDD, I want to let the test do the writing.  Essentially, sometimes the easiest path (brute force) is a good start.  From there I tweak it, then I write the test.  I don’t want to think about the problem too much, unless I’m stumped.  Then I bust out the pen and paper and start writing down ideas.  But I’m going to write a test first, way before I write an ounce of code.  I’m not going to implement more than I need to without writing the second test.

I’m not a genius and that is a good thing.  I believe if I can solve these problems, so can you.  That’s why I start out the easiest solution first, be it may be brute force.  It gives me to make something abstract into something concrete.  Then I can start to write testing, then using my tests to implement a solution.