I’ve been making apps since iOS 2.2. People tell me I’m good at it. Meh. There’s always a bigger fish. I love what I do, so chances are I’m not horrible at what I do.
Today was the first day where I used Test Driven Development to actually develop code. Don’t get me wrong; it’s not like I don’t write unit tests. I do. But what I’m referring to right now is where you actually are given the start and passing conditions of a test before there is any code written at all. In my field of work, this never happens. The design is ALWAYS a moving target. Nothing in the startup world is ever known in advance, so although you could write unit tests, it doesn’t always make sense.
I’ve recently been working on the implementation of the rules of Canadian Ice Hockey. (Don’t ask.) The sport itself seems pretty straightforward. Put the puck in the net. Goal. Increase Score. No way! There are a lot of complicated rules surrounding penalties, but thankfully there is a referee’s handbook that goes over all the complicated scenarios and tells you what the result should be.
Perfect for TDD. I literally wrote all the unit tests before I wrote the code that would produce the expected results. I love it because I have to be honest; the solver code I wrote just “feels bad”. I’m not even certain how parts of it work, and I only wrote it this past week.
What unit tests tell me is: It doesn’t matter! As long as the tests pass, the code does what it’s supposed to do. Very satisfying.