Last week we looked at a few excuses developers give for not testing their code as they develop it (Excuses For Not Testing). We finished that by mentioning that most of the code you write simply isn’t testable. You can’t practice Test Driven Development on something that isn’t testable in the first place.
And there, folks, is why Johnny can’t test.
But, it’s not Johnny’s fault.
Think about what makes code testable. At it’s core, testable code is loosely coupled. But what do we mean by “loosely coupled”?
Well, let’s start with the large picture. Assuming you have a mult-layered architecture. That is, you have you code broken out into View, Business Rules, and Data Access. Raise your hand if your business rules access your view directly. Would you be able to test your business rules without your view?
At a finer level of detail. How much of your code creates the objects it needs within the same class, or worse, the same method, that will need it? Without using a Dependency Injection framework, could you swap out any objects your class uses? Have you even heard the rule, “Classes should either create things or do things, but never both within the same class?” If you did that, how much more testable would your code be?
If you were to write a test for a method, how much setup work would you have to do? If it is more than a few lines, your method is probably doing too much, either directly or indirectly. You’ll need to find a way to make it do less.
Maybe in future post, I’ll address some of these issues in code. But for now, I just want to address the problem.
Again, it isn’t Johnny’s fault that he doesn’t know this stuff. Think about the code samples we tend to look at.
When is the last time you saw sample code that was testable?
Short rant here, but I’ve been working with EXTjs (version 4.x) for the last year and a half. Sencha will tell you that this uses a MVC architecture. But what they mean by “Controller” really functions more like a “ViewController.” That is, the controller is tightly bound to the view that it handles events for. The way they have things setup, you access View elements by getters that are automatically generated for you in the view.
The problem with this is that you can’t really test the controller logic without bringing along the view.
Sencha isn’t the only company who does this. Most of the sample code for WebForms did the same kind of thing.
Now, the reason this is an issue is that sample code is how most of the newer programmers are learning how to program.
I heard recently that statistically, because of the growth of the industry, half of the programmers available have 5 years or less of experience. I don’t know about you, but the first 5 years of my programming career, I was still figuring out how to program. I wasn’t thinking about architecture issues and I certainly wasn’t thinking about formal testing. From what I’ve seen of the new recruits, I don’t think they are either. Shoot. Some of the ones I’ve interacted with couldn’t code themselves out of a paper bag without help.
And so, what’s the conclusion to all of this?
I don’t know. Maybe the first step is to admit that we have an issue here and that the issue is so much a management or time issue as it is an education and laziness issue. That the code we generate shouldn’t assume that people will take the code and adapt it into testable code, but that we should write testable code as our sample code. Maybe colleges should teach basic software architecture and TDD as part of the curriculum. Maybe those of us who know better should just start testing and figure this all out well enough to explain it to others.
Other Places Talking About Testing
- Adaptive Code via C#: Agile coding with design patterns and SOLID principles (Developer Reference)
- Writing Testable Code
- Testable Code Best Practices
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