I know that this might be ahead of my post progression (last time I was still using PHP), but I had this thought go through my head yesterday while working, and thought it would be better to get it out of my system.
Isn’t It Just Writing More?
Yeah, that’s what I used to think too. I thought it was a waste of time, and just one more thing to do. I write a piece of code, fire up the browser, it works or it doesn’t, and go from there.
I went along this path for quite some time, and I’m willing to bet that you already know what would CONSTANTLY happen.
- Make a change.
- Test it in the browser.
- Works 🙂
- OH %$&$*, I FORGOT ABOUT THAT OTHER CLASS!
- Make a change….
I knew that this is why I was supposed to test, but I still didn’t really get it. I tried Cucumber, and it seemed like I was spending so much time writing features for trivial tasks like signing-in.
I didn’t know how to write a good test. It was just more work that was slowing me down, and it was actually easier to just deal with the headaches of unexpected consequences.
So, What Changed?
I started to finally grasp RSpec. I still wrote “bad” tests, but they did eliminate some of problems.
I started to see why this was important, and how it would help me avoid those errors where I just forgot that there a method was being used in multiple places.
The problem I still had were the “easy things.”
Do I really need to test adding a full_name method on a class? I’m just making a small change, and I know it’s fine, it’s no big deal to just change it.
95% of the time, this was probably true. I did know what I was doing with a small change, it it wouldn’t hurt anything to just do it. Was it worth going through the whole process just for that last 5%?
What turned me was another habit that this led into: too many times I found myself saying, “I can just change it on the server, and update my code locally later.”
I don’t have to tell you why this is a horrible idea.
Where I Am Today
I thought to write this post today, because yesterday I started to think that I’m starting to “get it,” with TDD. I was writing some simple methods that would send confirmation emails, and I was disciplined in writing a failing test, making it green, then moving forward.
Then came the time for the second method that just sent a different type of email… “Well, I’m awfully close to just copying the first… just write the method and you can test it later.”
“NOOO! Just take the 2 minutes and write a failing test first, you know this!”
And I did. And it took less than 2 minutes. And I felt more confident that everything worked.
I had my tests passing and was ready to deploy, when I had almost forgot to run the entire suite. OK, OK, I’ll run it first.
“Wait, a failing test? Why? Oh, it’s because I that other controller spec calls it too.”
I go in to update it and remember that I wrote the spec a long time ago and it’s very tightly coupled. This is going to need more than a quick change on 1 or 2 lines… “I know where it is, I can just deploy and refactor the spec tomorrow when I have more time.”
I think I am finally learning to love TDD