I Should Have Unit Tested

Ok, it’s confession time. A couple weeks ago I started a working on what I thought would be a very simple app. It’s essentially just a tableview with sort/filter options to keep track of what the 60 or so engineers in the department are working on. It would be stand alone, with the data entered and updated manually. I expected to be the only one using this app, so I chose to just throw it together without unit tests.

What? I know, right? What was I thinking? I was thinking that TDD didn’t make sense for what amounted to a simple prototype. I was thinking that TDD didn’t make sense if it was a personal use app. I think I wasn’t thinking clearly.

So tableviews are fairly simple creatures, with the SDK doing all of the heavy lifting. At the same time though, creating unit tests for it is fairly simple also, since it’s behavior is so well defined. But I needed more than just a tableview. I need a data entry screen to manually enter and edit the 60 engineer records. And that’s where the problems started occurring.

Keyboard dodging is a bit tricky (scrolling an entry field so it isn’t under the keyboard when it appears). I spent a lot of time in trial-and-error getting it working, and it still isn’t working correctly in all situations.

And data needs to be converted and formatting to and from dates and percentages. And that starts to get tricky. Again, I spent a lot of trial-and-error time getting that working.

But then I hit a strange bug, and have spent the past couple days trying to debug it. And then it struck me: the time that I had spent debugging this code could have been used to create unit tests first.

So consider this my formal apology to everyone. I’ve been espousing TDD for a long time, and using this exact situation as one of the compelling reasons. Sorry, I guess I fell of the TDD wagon, but I’m back on now.  I’m restarting this project, and you can be sure that I’ll be using TDD for everything going forward.

Leave a Reply