As I started my own journey into unit testing, I slowly began to realize that it was really easy to come up with reasons to NOT test my code as I was writing it, even once I understood what that was supposed to look like. The reason I think most programmers don’t unit test code, once they understand what it is they are supposed to be doing is that they don’t feel like they have permission.
To this I also answer, “How much permission do you need?”
Do you really need permission?
Do you ask for permission to compile and link the code?
Do you ask for permission to write every line of code to make the system do what it should do?
Do you ask for permission to run your code periodically to make sure it does what you had in mind when you wrote the code?
Do you periodically add code that makes you feel good but is not directly related to the task at hand? (Admit it, I don’t think I know of any programmer who doesn’t.)
Then why do we feel like we need permission to write unit test for our code?
Are you convinced that you need test?
We don’t write test code because we aren’t convinced it is necessary to do the job we’ve been given. We complain that our managers don’t want us to write unit test. But the problem is that you asked for permission in the first place. And, by asking for permission, you’ve basically told your manager that unit testing is optional. Your manager has said “no” because he thinks YOU think it is optional.
It’s not your manager’s job
It isn’t his job to understand that not testing will produce technical debt. He’s not even interested in understanding what technical debt is. All he cares about is this. When will this project be done? When you say it is done, will it work as expected or will it have a lot of bugs that need to be fixed yet?
Most of the managers I’ve worked for in the past will accept whatever number I give them once they understand that when I deliver the software to them, it is going to work. In fact, I’ve even gotten asked to do jobs BECAUSE my code tends to work more often than anyone else they know who could do the job.
Now, I will admit, that in some cases there are places where you’ve been explicitly told to not create unit test. But even here I will assert it is because someone asked management the question.
And so, we need to evaluate why it is we think creating unit test are optional. Probably because what we’ve been doing for so long seems to be working and, when we try to incorporate unit test, the process seems slower. And it is. Initially, writing unit test is slower just like writing using a new language or a new framework or anything else new is slower than what we know. But the ultimate efficiency that writing unit test as we code provides has been proven to more than offset the learning curve involved.
There is one other valid reason for not testing and that is, we simply don’t know how. This is almost as big of a reason as not believing it is worth while. But, I think if we thought testing was really worth while, we’d start testing and figure it out as we went along.
If you think about your career, I bet there are a lot of things you know now that you didn’t know when you started out. The fact of the matter is, most of us learn on the job. We start out with basic skills, but it is the day to day implementations that improve those skills.
Don’t let the good enough be the enemy of the perfect.
Don’t let the good enough be the enemy of the perfect. Your first set of test will be garbage. As you stick with it, you’ll wonder what you were thinking when you wrote your first test. But this should not deter you. This is what happened when you first started coding. Maybe it is still happening. No worries. It is the practice that will make you better able to write tests and better able to write code that is testable.
And there is another reason we don’t test. Most of the code you are currently writing simply isn’t testable. But, that’s the subject for another post.
Other Places Talking About Testing Code
- Quality Code: Software Testing Principles, Practices, and Patterns
- Developers, Test Your Code!
- Testing Concurrent Code
Other post in TDD
- Why Don't You Practice Test First Development? - February 20th, 2014
- Test Driven Specifications - February 25th, 2014
- Unit Test Structure - March 11th, 2014
- When You Really Need All Of Your NUnit Test In One Class - March 18th, 2014
- TDD Isn’t All About Testing - March 25th, 2014
- Automated Web Application Functional Testing - April 1st, 2014
- What Not To Test - April 9th, 2014
- Make Your Test Work For You - April 18th, 2014
- Don’t Comment Out That Test - April 24th, 2014
- The Proper Function of QA - May 1st, 2014
- TDD Saves Time – A Story - May 22nd, 2014
- It is called "Unit Testing" for a reason - August 28th, 2014
- Is Your Architecture Crippling Your Unit Testing? - September 4th, 2014
- Selenium Performance Improvements - October 2nd, 2014
- Technical Debt Is Inevitable - October 16th, 2014
- NUnit, Unity Dependency Injection, MOQ and Private Fields - October 23rd, 2014
- NUnit & Visual Studio - December 4th, 2014
- Software Architecture without Test Driven Development is DANGEROUS! - January 29th, 2015
- NUnit Test Code Structure - February 5th, 2015
- Excuses For Not Testing - February 26th, 2015
- Why Johnny Can't do Test Driven Development - March 5th, 2015
- Changing Habits - March 19th, 2015
- 100% Code Coverage Possible? - March 26th, 2015
- TDD Gamification - Turning Test Driven Development into a Game - April 23rd, 2015
- Run NUnit from Visual Studio - April 30th, 2015
- The Parable of The Road Line Painter - May 28th, 2015
- The Fallacy of Motion - July 23rd, 2015
- Test Driven Learning - An Experiment - March 24th, 2016
- 3 Reasons You Believe 100% Code Coverage Is Impossible - May 26th, 2016