TDD Day 4

Published on: January 8, 2014

What did I do today?

I’m continuing on at Coders Dojo, today I worked on Roman Numerals. I've heard this problem talked about, but haven’t actually worked on it myself. It was harder than I expected (and involved a lot of Googling for the correct way to convert numbers to roman numerals), but I did finish it with all green specs.

I also watch the next video from RubyOnRailsVideos about TDD. This one talked about writing pending specs before you get properly started to give you some scaffolding to work with (among other things). I tried to work with that today. I started by going through and writing up an outline of how I thought the tests should go, in increasing difficulty, and with clear titles. Overall I think it helped me stay focused. I was certainly much better at Red-Green-Refactor, particularly the refactoring bit.

Reflections

I found that once I had a couple of hard coded examples of code that passed specs I found it much easier to move to a more abstract implementations. Normally I would just head to the abstraction since I know that’s what I'll have to end up with. But focusing on the “least code possible” for a green test it was easier to work out what the final code should be. So there’s something concrete and useful about using TDD...

As with the prime number converter I looked around for a solution to this kata after I had finished it. Other people solved it more simply, although I felt like they were cheating. An interesting idea, if it’s voluntary work done for your personal betterment, can you really cheat? They simply wrote more cases for the base dictionary (i.e. 4, 9, 90, etc.). As I said, I feel like this is cheating. It seems like your application should only know the minimum numerals available, and not need to look up any additional combinations. At that point, why not just hard code all of the solutions?

Well, because that would be extremely tedious, and with the few additional numbers these other solutions used they were able to save a considerable amount of code. In the real world, theirs would be the preferred solution by far. It was far simpler, had fewer lines of code, and did not hard code anything that was likely to change in the future (those Roman numerals have been around for a while). So although I may feel self-righteous about my solution, I do believe theirs is preferred.

I do think I’m starting to see more of a use for TDD, and testing in general. Refactoring the code was much easier with all the tests I had to make sure I didn’t forget anything small.


comments powered by Disqus