Addressing Arguments Against Unit Testing

This was originally posted on my blog. Thanks for taking the time to read it here!

I re-read my post about convincing a team to start unit testing and realized that, when addressing developers, I really only talked about resisting the urge to go crazy when refactoring. I didn’t, however, actually address convincing them to start testing beyond the general arguments for unit testing. One place that I recommend everybody start is this course created by Angie Jones at TestAutomationU. It’s got lots of great content related directly to this conversation, it’s well done, and it’s free with the exception of your time (of course). I recommend it highly enough that you should go NOW and, at a minimum, start the course. (And no they’re not paying me to say this) Now that you’re back, let’s get on to what I originally planned to talk about. That is the arguments that the developers that I work with have against testing even though they told me that the general benefits of testing I presented make sense.

Arguments Against Testing

My project is late

As I’ve worked with my team to start testing, I’ve heard several variations of this argument which are:

• I’m already over my estimated time to finish, I haven’t started writing tests, and we didn’t estimate time to write tests into my work
• We’ve been working on this for a while and our clients have started asking about time to completion (or I’m worried they will start asking soon)

Both of these statements end in the developer asking how they could possibly start testing now on this specific project. The fear surrounding trying to test when it hasn’t been planned for is totally valid. And yet my response to this is usually: “when are you going to have a project that isn’t under a crazy deadline?” If the answer is that you’ll never have time you should start planning time for testing on your next project. Or, better yet, the next part of your current project that you’ll be responsible for. Testing will make things busier and, possibly, more stressful in the short term but will reduce those things greatly over the long term as the code base becomes tested and reliable. In my experience these questions come up in environments that have lots of work to do and where work is expected to be done without delay in the quickest manner possible. This is precisely the case where testing will help the most over time and is the least likely to be supported by schedule, users, clients, management, or any combination of the above.

My project is high priority

This is really a variant of “my project is late” with the exception that the project is late before you’ve started working on it. Usually because it has high visibility to somebody in the company that can throw their weight around. Ok, that’s not always the case but, as in the case of a late project and until your team has developed good testing habits, you may want to punt until the next project to test (even though this project would benefit from testing). So far my answers have been “punt until the next project.” I really do want you to start testing BUT I want you to do it in a way that stands a chance of succeeding on project after project until it becomes habit.

The code I’m working on is too complex

Now we’re past the “I don’t have time” arguments into something that can be turned into actual tests. If your code base has been around for any significant amount of time, this is the issue you’re going to present me with as soon as you actually try to start testing. By “significant amount of time” what I mean is any code that has been developed without tests (per, as always, Michael Feathers in Working Effectively with Legacy Code). I will freely admit that your code is very complex. If it has been around for any length of time (and has survived its way to production), I have no doubt as to both it’s usefulness and complexity. That being said, that is not a reason for you to skip testing. It will simply mean that it will take you a lot of effort to:

• Figure out what to test
• Figure out how to test what you’ve decided to test
• Refactor the code so that it is testable

This will be HARD and will cause arguments about what, when, how, priority, and schedule. Hard, however, is not a reason not to test and the arguments are ok. They mean that you’re actively talking about how to make your code and team habits better; that is a GOOD thing. I promise you that the refactoring you’ll have to do will make your code better. I promise that the tests you write will become trip wires that safe guard further changes. And I promise that your code will become more understandable as you break it up and document it with your tests. I will just take time.

There is too much refactoring required

I spoke about this in my last post a fair bit so I won’t beat it to death here. Lots of refactoring means that it will take more time to get your code completely covered with tests. I understand that refactoring takes time away from fixing bugs and adding new features that are critical. I also understand that refactoring may lead to changes that are separate from the specific feature or but that you’re changing and that will cause more testing for your QA / UAT staff. Yes, this additional work is a pain RIGHT NOW but, in the long run, you’ll be rewarded for spending the time with reduced time for and more confidence in changes in the future.

Conclusion

TESTING IS HARD BUT NECESSARY. The benefits of testing apply to an existing code base but are difficult to get to. It takes persistence and the development of habits. But you’ll get there over time. I would love to hear what has worked for you or what issues have come up in your testing journey in the comments, on Twitter, or via email (taylor@taylorbuiltsolutions.com).