If you were to Google “Why software testing matters” you’ll probably get a result that discusses the purpose of software testing, and how it “minimizes defects” or “tries to catch defects early”… But none of them discuss why writing tests is good for the person behind the keyboard, who’s cranking out code most of the day.
To be different I want to share with you the reasons why automated tests can actually improve you productivity as a developer, decrease the amount of fear you have when you actually have to write new code or make changes to existing code that could actually break everything around you.
Plus some of my coworkers who tried to read my previous blog post complained that the length (the scroll bar is tiny) of my post was far to long. In an attempt to write shorter posts and condense some of the knowledge from my previous post and sprinkle some extra information from the experience I had gained practicing, I’ll write a series of blog posts discussing the principles of writing automated tests.
Is testing for me?
There you were polishing up your feature ready to be handed over to a tester for testing. Some time goes by, and he reports back that you shit doesn’t work and says to write better code. Yes, this has happened to me quite a few times before.
Okay so you’ve fixed the defect and manually dev tested your that your code in fact does work. Ha! Mr tester, see if you like it now! About 15 minutes later he asks “Are you blind rocky?” (considering the fact that I had stitches on my eyebrow after being hit in the face with a paddle) “you’ve fixed the defect but everything else doesn’t work, I can’t view member information anymore; fix your shit”! I thought that was working? It was working an hour ago… What happened? It was actually due to the fact that I had broken a service while doing my refactor/hotfix; you know, we all do that.
When I started writing automated tests all of that had changed. I felt like a new person. I sure was going to show John (tester) that my code did in fact work and didn’t stink.
I added my test cases and made sure the tests ran, all passed and I handed my feature over to John. “Rocky! Come here”… I felt like I had got him for good now. “See this?”, John said. “Yes what?” I asked. “null in the surname column. Fix your shit”.
Now that last case was on me. I forgot to add a test case in my automated tests that cater for that specific use case.
Other than that I felt productive. Automated tests were really helping me as a developer. Just this week I went quite wild a did a refactor thinking that I didn’t break anything. I ran my tests and almost half of them failed. This was immediate feedback and didn’t involve John. I did a
git reset --hard and decided to take things slow. Made a little change and ran the tests, another little change and ran the tests again (this is really the art of Test Driven Development which is explained in upcoming posts). I soon got the refactoring I wanted, my code is clean and my tests pass.
I handed my feature back over to John, and he tested it. Thirty minutes later he stuck his little thumb in the air and said you’re good.
I hope to have conveyed why testing in important and why you as the developer need to it to boost your productivity and ensure that your code is working as it should be.