“Have you considered working in another area in software, you don’t seem to have the right personality type to be a developer”…Said the head of development sat across the table from me. I sat, head down, a mere 18 months out of university having just delivered my first major product release being told that I was no good at what I do. I love programming, it has been my hobby since I got my first computer and it was the only job I’d ever wanted to do.
As I’m sure you can imagine, I was devastated but not entirely shocked. You see I used to rush through a task or bug to get to the next one or get distracted by something shiny. The best way I can describe it, is as a Magpie effect and, as I was being made aware of at that moment in time, developers are expected to be completer finishers and meticulous to a fault.
I was aware of TDD and I had tried to write some tests but I really struggled with how to make code testable and good unit tests that didn’t just test “stuff”. But this time I was determined to learn more and put it in to practice, it seemed like the perfect answer.
That was nearly two years ago now, I’ve grown massively as a developer since that day and TDD has been my gateway drug to professionalism. When I started off with TDD I thought it was about testing but when I look back at my journey thus far, it’s about anything but.
One of my biggest problems was rushing, I was always desperate to finish and I missed things or didn’t think them through properly. The first thing that writing unit tests helped me to do was slow down and break problems into much smaller chunks. Just taking a few minutes to consider how best to write the test normally exposes any concerns that need to be separated, edge cases and how the class or function will be interacted with. If I’m ever struggling to make a test pass, write a test or if I can’t make all the tests pass, it normally means I need to go back and look at the tests to see if I’m trying to solve too much in one go or if it has contradictory responsibilities.
The tests provide excellent documentation that is hard to argue with and stays in step with the code. This is key because it gives me an insight in to what I was thinking and how I intended on it being consumed. It’s, also, the closest to an interactive interrupter for C# I have used, which is great for rapidly checking assumptions and questioning your own code.
Overall it has taught me so much about architecture, design, good practice and maintainability of code. One conclusion I have to come is that unit testing has a very low regression value. At this moment in time I rarely, if ever, find bugs using unit tests. Yes they help to identify failure points but it’s not very often I find regressions using them. All they have done is shifted the pain point from if the logic works to if it all works together. My next challenge is step deeper into the world of the integration testing.