Ignoring Testing can be Explained, but Never Excused

Many individuals that practice software development will tell you the same thing; testing is vital. I’ve never worked at a place that “requires” automated testing. Any of the testing that we’ve automated was put in place as a way for our team to check ourselves. Those who have implemented it have understood its importance, and put something in place to benefit from it. In these cases, something is better is nothing. What I have dealt with at some jobs is testing as a manual process by the developer (and/or supervisors) to run the application and “eye-ball” the results. This isn’t how testing should work, definitely not how automated testing works and how dare you even bring up the term TDD!

If you don’t have a build server (with an assumed automated test suite) or have a project for tests, or have unit tests at all, there may be reasons for this. These reasons may be explained, but are never excused. I’ve heard or read the following:

• Writing tests takes too long.
• Writing tests is hard.
• It’s not my job to test.
• I’m in a small shop. We don’t do that. — or — It’s only me on this project. I don’t need tests.

These are valid explanations, but they fail to address the reason that testing doesn’t work for you. It’s not the fault of testing, it’s the fault of the situation you’ve put yourself in or gotten yourself into.

Writing Tests Takes Too Long

Tests do not take long to write. They’re usually no more than a dozen lines of code per test. This excuse can easily be refuted by the fact that tests should be quick to write. If they’re not quick and easy, it’s because your code base is composed of code that is not testable. If this is the case there are probably bigger problems with your project than the lack of tests. You’ll need to look to SOLID principles to increase the quality of your code. This needs to be a pre-requisite to building or maintaining any project.

Explained due to lack of project structure or poor code.

Writing Tests is Hard

Look for the most simple method you have in your project and write a test for it. You now have a way to ensure that this method works as expected when any other part of your project is changed.

        public bool IsPreferredCustomer()
        {
            if (IsLifetimePreferred)
                return true;

            if (ClubExpirationDate < DateTime.Now)
                return true;

            return false;
        }

Three simple tests can be written to ensure that this method does exactly what it is supposed to do. You create methods that checks each path through the method and asserts that the expected result is equal to the actual result.

Explained by lack of experience or laziness.

It’s not my Job to Test

Maybe the word “test” or “tester” is not in your job title. This doesn’t excuse you from testing your code. You probably test it visually before handing it off or checking it in anyway. Why not write code that tests it? If you make changes later, you can ensure that you’re not breaking previously tested code that worked. If at the very least, when you said in August that your code worked and now you added/modified something and it now “isn’t working”, you’ll be the first to know and the first to have the chance to fix it before handing it off to another team or even worse, a supervisor.

Explained by lack of commitment or carelessness.

I Work in a Small Shop or I’m the Only One on the Project

The problems with this argument are:

1. You could be making yourself look bad. Even if you’re doing a small project on your own. You probably want to ensure that your code is checked by itself. If you perform the development for a project and a year later the client hires somebody else to add to or modify your code. You have somewhat of a “proof” that your code works the way it should. This makes you a bit more credible for future work.
2. You also should add tests to your project because you care about your fellow developer. Have you ever been thrown head-first into a project to “fix it” and the project has no tests? You might be wanting to jump off a cliff instead. You have no idea what your changes will break because there is no guarantee that the code you modify isn’t going to break working pieces of code. Adding tests is a way of paying it forward. Unfortunately for me, I’ve never picked up a project that had previous tests in place. If I ever do, I will contact as many of the previous developers as possible and send them a thank you card!

There is no reason a small team shouldn’t be as confident of their code as a team of hundreds, or even thousands. Whether you’re working on a project of 3,000 Lines of Code or 3,000,000 LOC, the project is only as good as the work put into it.

Explained through the falsehood that small teams are not responsible for quality work.

Have You Heard Enough Yet?

I feel like I’m beating a dead horse. I also feel like those who advocate testing are also the only ones that have taken it up and actually done it. I’ve never read an article by, or talked to a single person who has done unit testing successfully and not advocated it as being extremely important. Once you open Pandora’s box, you can’t go back; if you’re testing, you don’t know what you’re missing.