Home » TDD » Why Johnny Can’t do Test Driven Development

Why Johnny Can’t do Test Driven Development

ppl-kid-05Last 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

 

Other post in TDD
Summary
Article Name
Why Johnny Can't do Test Driven Development
Description
Everyone knows they should practice Test Driven Development, so why do so few do it? Here's the real reason. No excuses.
Author

Related Post

  • Excuses For Not TestingExcuses For Not Testing 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 […]
  • Test Driven SpecificationsTest Driven Specifications Several years ago, long before the community was actively talking about Test Driven Development, I worked for a short time at a company as a “bug fixer.”  That was my role.  They […]
  • TDD Isn’t All About TestingTDD Isn’t All About Testing While the artifact of Test Driven Development is test code, what you get out of test driven development far exceeds the test themselves.  Maintainable Code By writing test first, […]
  • What Not To TestWhat Not To Test Many people believe that implementing Test Driven Development means that you need to have a test for every line of code in your system.  When  they start thinking about TDD in […]
  • TDD Saves Time – A StoryTDD Saves Time – A Story I recently had an experience writing code that proved to me, once again, that using Test Driven Development really is faster than the way I have been working.You will remember a couple […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback

  • Pingback: Dew Drop – March 5, 2015 (#1968) | Morning Dew()

  • Eric Lubisse

    Good points Dave. I’m not sure the problem is as big as you suggest. As you’ve said the industry has grown tremendously. I’d guess the total number of programmers is in then tens of millions. There is a wide spectrum of software applications. From code that runs in our domestic appliances to code that controls rovers on a distant planet. Years ago I took a little course in testing. One of the things the instructor impressed on me was that concept of the burden of proof in relation to software applications. Testing was a means for me to prove that the system developed worked as expected. But in today’s world is such a burden really necessary? If I download an android app to play tetris I might be annoyed if it crashes but is a big deal? Now if I’m performing a checkout on Amazon or trading in FX I wouldn’t be so tolerant of failures. My point is that different applications demand varying degrees of rigour in terms of development practice and testing.

    • I’m not sure how your comment relates to the the article other than the word “test”.

      There are many other reasons to test other than ensuring that the code works. Many of these reasons have been addressed in articles I’ve written previously and that I’ve linked to at the bottom of the article.

  • downlaod lagu terbaru

    wow geat

  • I think you nailed it in the last paragraph. I was thinking exactly the same thing about my first years as a programmer.

    But recently I see many young programmers come from college that are really better educated than my “older generation” at the same age. I talk with them and I think “wow, I really wish I knew all that when I was starting programming”.

    So programmers are getting more and more, but education is also getting better – as long as you are willing to put some effort and learn. There are much more learning resources on the web now, compared to 10 years ago 🙂