Home » TDD » What Not To Test

What 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 this way, they start to feel overwhelmed and quit before they even start.

I know I did.

In fact, I’ve seen suggestions on places like StackOverflow that suggest as much.

But there is code in your application that you shouldn’t bother to write a test for.

Generated Code

Generated code includes any code that uses some automated process to create code your system is using.  This would include code that was written by Entity Framework, NHibernate, or code generators that you may have written.  Of course, I’m assuming that you’ve written test for the code generators that test both that they generate the expected code and the code that was generated works as expected.  But to write a test for every instance of the code the generator writes is quite a bit of overkill.

Simple Getters and Setters

If all your getters and setters are doing (properties) are retrieving and setting some backing store, there isn’t much point in writing a test for them.  One would assume that the code will get tested in the course of testing the code that is ultimately using the getters and setters.

Third Party  Libraries

While I know it isn’t true, you have to assume that the third party library you are using actually works.  If you can’t assume that much, you should probably write it yourself.

Your Thinking About It Wrong

I would argue that if you are thinking about what you should write a test for, you are probably still thinking of Test Driven Development as something you do for the sake of testing rather than for the sake of design, maintenance, and problem solving.

When you write code, you should be thinking, “What problem am I trying to solve?”  Or better yet, “How can I state the problem in terms of a ‘When/Then’ statement?”

When you think about the problem this way, what you test becomes that When/Then statement.  The class name for the test becomes When and the test becomes Then

public class WhenTheCodeIsInStateXAndIPerformActionYOnIt
    public void Setup()
        // Setup When
        // Perform Action

    public void ThenItShouldEndUpWithZState()

When you do this, the question no longer is about how much code you have to test, but instead becomes “Have I written a  test for every reasonable condition this class may encounter?”


Other post in TDD

Related Post

  • 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, […]
  • When You Really Need All Of Your NUnit Test In One ClassWhen You Really Need All Of Your NUnit Test In One Class Last week I proposed a structure for unit test that follows the pre-condition, action, post-condition workflow.  Basically what you would see in a Use Case document. The result of […]
  • 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 […]
  • Why Johnny Can’t do Test Driven DevelopmentWhy Johnny Can’t do Test Driven Development 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 […]
  • 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.