TDD Day 2

Published on: January 5, 2014

What did I do today?

Second day of working with TDD and I actually got to write some code! I tried to work with Coders Dojo, but their web interface only seems to allow Unit Test (we use RSpec at work, so that’s what I'd like to start with), and I couldn’t correct yesterday’s command line tool/xcode issue (hopefully I'll be able to download xcode properly when I get to work on Monday). Anyways, I used their site to get some ideas of what to work on and decided on the classic FizzBuzz. An oldie, but a goodie (aka, not sexy but gets the job done).

I almost never use Ruby on its own, and I have no experience testing just Ruby. So I watched the second installment of Test-Driven Development in Ruby to help me get everything set up nicely to work with RSpec without all of Rails. Once I had all my files in place it was time to get started.

Ok, I'll admit I've done FizzBuzz before - the premise wasn’t hard. I’m not sure if that’s cheating, or just helping to isolate the problem (I’m hoping for the latter). But doing strict TDD is new to me, and certainly caused me to slow down a bit as I went. I walked through each of the bullet points listed on the Coders Dojo site, wrote a test for that rule, failed my new test, updated the code, and passed all the tests (I’m learning to love green already!). I did forget to get a red test for one of the steps, and had to go back to fake it, but I was good about writing my tests first.

Reflections

I don’t know what to test.

fizz_buzz only takes one parameter - is that something I should test for? On the one hand, so long as fizz_buzz doesn’t break when it is only passed one parameter (i.e. any additional parameters are optional), it doesn’t matter, and not testing for it is alright. On the other, what on earth is going on with your fizz_buzz that you want more than one parameter?? If you're doing that kind of thing, something has gone wrong with the function and shouldn’t you know about it? I guess that’s what Sandi Metz means by “arrogant programming” in Practical Object-Oriented Design in Ruby. Who am I to say what fizz_buzz will need in the future?

How many cases should I test? I only tested on the most basic (3, 5, 15, 1), since that seems to be the absolute minimum you could do and still have 100% code coverage. (Yes, I know we shouldn’t always shoot for 100%, but since this is practice it seems like a good idea.) But on the Coders Dojo website they list a bunch more test cases (1, 2, 3, 4, 5, 6, 10, 15). Is that overkill? Am I under testing? How much is “enough” vs. “too much”?

Hopefully the next 28 days will help clear all this up for me! But if you have any suggestions/ feedback/ tips please let me know in the comments!


comments powered by Disqus