If you think this article is going to be about developers not knowing how to use Unit Tests, that’s not what it’s about. Unit testing is an art form in its own right. When a developer has extensive experience in writing unit tests, the application becomes beautiful. No more random bugs that you have to tackle in a class that you didn’t even touch but was affected by your code elsewhere. No more wasting unnecessary time; just run the tests after your changes and watch them go.

You could argue that even if the developer is inexperienced, writing any form of unit tests could be beneficial, even if they’re not testing for everything. There’s no speed penalty on prod; after all, unit tests are removed when packaged for production environments. They’re only there to help the developer write bug-free code. So what’s the problem?

Capacity

Have you ever wondered why you’re so stressed out at work? A good portion of the time it’s due to your workload. Companies tend to run at or near capacity, usually opting for slightly under-capacity. When you incorporate unit testing properly, it starts to take significantly longer to complete your projects. When you present to leadership the applications that you’re working on, they will start to question your pace. The product needs to be out in the wild to attract any attention or it needs to be used by the staff yesterday.

Trying to explain to your business side that you’re incorporating unit tests to future proof the application is a losing game. All they see is that the software that they requested for is taking forever and maybe they need to start looking for someone else.

It’s a Hard Sell

If you’re working for a software development agency, you’ll have a fun time trying to sell unit tests to your client.

• The developers should already be proficient in writing code.
• What do you mean you have to write a test for everything that you create.
• Why don’t you just hire more senior software developers?

The customer doesn’t know what it means to be a senior software developer. They just want to make their app as quickly and as cheaply as possible. When you bring up the amount of money that it will take to create unit tests, the customer goes into shock. Even if you hide it within the development cost, they will compare your SOW to the many other ones they received and will likely discard it; they won’t even ask why your SOW is significantly higher than everyone else’s.

It May Be Too Late

The application may be too large for you to make any significant effect. If you’re trying to retroactively create all of the unit tests that you want or need, it would take a significantly more amount of time than if you created them while you were writing the code. If the customer is willing to pay for it, go for it, but to do it just because you were irritated at the amount of time the last bug cost you, is usually not the answer.

You May Actually Be Wasting Time

Unit Tests can become a form of an addiction. I’ve seen plenty of developers write unit tests for every single case imaginable. So much that it actually becomes a time waster instead of a time saver. If you’re missing your deadlines constantly, it’s time to rethink your unit testing strategy.

What Can You Do If You Really Want to Write Unit Tests?

There are a couple of things that you can do to incorporate unit testing into your application.

Do it the wrong way. Write a Unit Test after you discover and correct the bug. This will ensure that you’re not going to experience the same type of bug in the future.

Go work for a mature company with a reputable product. These companies have proven that their product is successful in the marketplace and can’t afford to have it go down. These are the types of companies that focus on unit testing to guarantee that their product will be error free. The last thing that they want is for a developer to crash another portion of the application and for QA to not test it.

Do it in moderation. You can devote a small portion of your day to writing unit tests. This shouldn’t affect your performance and the application will be better for it.

Finally

Although the world would be a much better place if every application was done with Test-Driven-Development in mind, unfortunately that’s the the utopia that we live in. TDD is great but is difficult to justify to individuals that start doing the cost-benefit-analysis in most situations..