There is also another side of Unit Tests. Some companies are so fixated they aspire to have 100% Unit Tests coverage and they make programmers write Unit Tests for legacy code for no reason. Just for the sake of having Unit Tests. … [I] wonder if you had any similar experiences and what you think about this approach. I guess the 100% extreme is better than no tests at all, but it can make the developers very bored and feeling useless.
And my initial reaction to this was, “WOW! So much to respond to here. I think this is worth a blog post.
Is 100% realistic?
So, first, the question of 100% coverage. Is that a realistic goal? And the answer of course is, “it depends.”
The first dependency is, of course, “what do you mean by ‘100% code coverage’?”
Do you mean you need tests for not just all of the code you wrote, but all of the code your tools wrote for you and all of your third party libraries? If 100% is inclusive, I’d lean toward 100% not only being not realistic, but also not necessary. Although, in a highly critical system, you’ll probably want to do some kind of vetting of the tools and libraries you are using. But by the time you are using them, you should already know that they work, the only thing you won’t know for sure is if you are using them correctly. In this case, you are looking at integration tests and not unit tests.
The second dependency is, “Is the code testable?”
This is a little trickier to evaluate, so let me illustrate. There is code that isn’t testable that should be. I’m not talking about that code. I’m talking about code that just can’t be tested.
Let me illustrate.
I’m working with EXTjs which uses their proprietary implementation of MVC. The part that is particularly interesting is that the View part of the architecture is basically a JSON object that defines what the view looks like. While you can put in code that performs some action, the fact of the matter is that this code, when coded correctly, doesn’t really DO anything. So, I would ask, how would you test this? Sure I could put it in a test harness and run it through some sort of parse routine or something, but unless you can say, “when I do this, this other thing over here should be true (or false)” you really can’t test the code. A class that has no methods is basically a structure and structures can’t, by definition, be tested.
On the other hand, I wrote some code once in WinForms that I was able to get under test and execute by calling the methods directly in the form. I would have been better off moving that code into a presenter class so I could test the functionality separate from the presentation (view) and marked the view as untestable.
Finally, I have to ask, “Is refactoring allowed?”
This is legacy code we are talking about. And legacy code is notoriously hard to unit test. As I mentioned a couple of weeks ago, in order to write unit test, the code has to be testable in the first place. So, if the code isn’t in a condition that it can be unit tested, and you aren’t allowed to make the code testable, then either 100% code coverage isn’t possible or you aren’t unit testing. It’s that simple.
Testing is boring
Next, I’d like to address the issue of testing being boring. I can understand this. Most of my day is spent unit testing code I’ve previously written because when I wrote it, I wasn’t as good at unit testing as I am today.
But, you know what I’ve found along the way? That by making sure the code is covered 100% it has made me think about how I’ve structured my code and it has made my code more maintainable.
But, mostly I find testing entertaining because I learn just a little more about testing. I get to prove to myself and my peers that writing unit test really does find bugs we didn’t have any idea were there. I get to perfect my craft just a little bit more.
Here are some things to consider about the statement that “testing is boring.” You may not like what I have to say, but keep in mind, I don’t know you and I don’t know Kris. I just know what the research says about the state of being bored.
feeling impatient or dissatisfied, because you are not interested in something or because you have nothing to do.
People who get bored easily are usually anxious people. They’re also having quite a low level of self-esteem. If you’re constantly challenging yourself by trying to stop what you’re doing, because you don’t “like” it, you end up considering yourself an inappropriate person.
One Of My Professors Said
Boring people get bored
Personally, I find that I’m most bored when I have something else I’d rather be doing. It isn’t so much that I don’t want to do what I’m currently doing as I’d rather be doing something that I can’t currently do. I had this experience on Friday because on Thursday night I had found an article on SEO stuff that I desperately wanted to start putting into practice.
What I’m suggesting here is that if you change your perspective from one of, “this is a ridiculous idea” to “this is a challenge to be met” or “this is an opportunity to learn”, or even (to address a specific comment that started this post) “I get to make my this application more bug free.” you may find that the boredom leaves.
Treat it as a game. Maybe pair up with people on your team and see who can discover the most bugs during the day. Create a leader board. Since you have to do this anyhow, make it fun.
Other places talking about 100% code coverage
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
- What If Unit Testing Wasn’t Necessary? #noTDD - June 27th, 2017