I confess that the title of this blog post is clickbait. I feel a little ashamed that I’ve stooped so low to get your attention.
But as long as I’ve got your attention, there is a bit of truth in the title as well. The truth being that in the course of my career as a software developer, I’ve become very good at creating and believing my own excuses for not writing automated tests. When I fail to write tests, I fail to ensure quality in my own code. As a professional software developer, that is not acceptable. (See our software development capabilities)
In this blog post I’ve compiled a list of 10 excuses that I’ve used or heard from others that are reasons to not write repeatable tests for one’s own code. Hopefully you will see the humor in my excuse list, even if some of them “hit a little too close to home” as they do for me. I’m going to use this list as a reminder of how silly my excuses sound… and to just write the tests.
Excuse #1: I Don’t Have Time to Write Tests
I promised my boss that I could get three-times more code written in the next few days than I know I’m capable of producing and something must give. Writing unit test code almost always takes longer than writing the code itself, making tests the biggest corner I can cut to save time. “Over promise and under unit test” are words to live by when you’re a developer; there is no other way to meet deadlines and stay sane.
Excuse #2: My Code Works Right the First Time
I started writing code before some of my fellow software engineers were born, so I must know what I’m doing, right? My code works “as written” and there is no need to write more code to verify what I already know.
Excuse #3: I’ll Never See This Code Again
I’m two weeks away from transferring to another department and therefore there’s no point in unit testing my code. Any issues that arise with what I wrote soon won’t be my problem to fix. Yippee!
Excuse #4: No Tests are My Team’s Culture
Ever since I started working at my current employer, I’ve only worked on existing code. None of the code has unit tests and adding tests would be nearly impossible as the code was clearly written without test-ability in mind. Even the senior developers and architects don’t write tests. Every time I bring-up the term “unit tests”, I hear grumbling from my own peers. I don’t want to make waves and get the rest of the team mad at me by adding tests. Writing tests is a career-limiting move!
Excuse #5: “Throw It Over the Wall” and See If It Works
My job as a software developer is to write code, not test it. To keep-up with my workload, it only makes sense to get my code to the quality assurance team as soon as possible so they can see if it works according to the requirements. They’ll let me know if it doesn’t. While they’re testing my code, I can start working on the next urgent feature.
Excuse #6: Defects Ensure Job Security
It’s my understanding that quality assurance professionals live for defects and are often given a financial incentive based on the number of bugs found. It almost seems like skipping unit and integration tests might actually help keep them employed! I’ll catch the big bugs, they can catch the lil’ nit-picky ones. “I’ll scratch your back, you scratch mine.”
When a bug does sneak-by QA and into production, I’m the only one that really understands the code I wrote and so it’ll eventually land back on my plate to fix. In a way, I’m pretty much ensured a job as my employer would be in a world of hurt trying to understand my code without me.
Excuse #7: It’s All About the Story Points
Story points are the Bitcoin of an Agile project… No one really knows what they’re worth, but it’s cool to have a lot of them. Nothing boosts the ego like consistently finishing sprints with the highest number of points. By skipping all the time-consuming unit tests, I radically increase my story point count which is a metric that is clearly visible to my manager. This method works particularly well with greenfield projects where the code hasn’t been deployed to production yet. It also works well when the project’s “definition of done” ends prior to releasing code to production where all the annoying end-users find the most annoying bugs.
Excuse #8: Who Tests the Tests?
If the unit test code I write is based on misunderstood requirements or has a bug in it, the tests will give me a false sense of security that my code is good when it is not. Once my misunderstanding is exposed, I’ll save a lot of time in correcting the bug if I don’t have to correct all the unit tests as well.
Excuse #9: Unit Testing Leads to Refactoring Which is the Second Biggest Waste of Time
The unit testing mantra of “red, green, refactor” is for those who have too much time on their hands. Why refactor code when it will be obsolete in a few months? Isn’t that like rearranging deck chairs on the Titanic?
Excuse #10: Reoccurring Defects in Production are Exciting
What’s more exciting than getting the team together in the middle of the night to fix a defect that was ‘fixed’ several times before but keeps coming back? Even better, having multiple recurring defects that randomly pop-up is more exhilarating than playing “Whack-a-Mole” at Chuck E. Cheese. Writing “emergency code” in a production environment in the middle of the night with executives watching your every keystroke is a total adrenaline rush!
What Are You Doing to Ensure Code Quality?
I created this blog as a reminder to myself that code quality starts with me. From my favorite book on unit testing, The Way of Testivus, “If the code deserves to be written, it deserves to have tests”. I know of no better way to ensure quality in the software that I write than to start with unit tests.
At an organizational level, utilizing an automated DevOps process to automatically run a comprehensive suite of tests prior to committing code to source control is a great start to ensure a higher level of code quality. Catching a breaking change as early as possible in the development cycle is by far the least expensive time to fix a bug.[^1]
If you’re interested in improving your team’s code quality starting with DevOps and automated testing, we can provide an assessment service to accelerate its adoption in your organization. Contact us to learn more.
[^1]: National Institute of Standards & Technology. May 2002. The Economic Impacts of Inadequate Infrastructure for Software Testing, 5-1 – 5-8. https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf
