Sunday, January 22, 2017

Top 10 Excuses Programmers Gives to Avoid Unit Testing

Though everyone loves unit tests and everyone agree with benefits they bring in, when the time comes to write them, you will see a lot of excuses, even from some of the more experienced and senior developers. At the heart of the problem of not writing unit tests or enough unit tests they are two things, first is time pressure i.e. you don't have enough time to complete coding forget about writing unit tests. This problem comes due to erroneous estimation i.e. only estimating time for coding and not including unit testing as part of development. This is also our first excuse, so we'll see it in a short while. The second reason is laziness and ignorance i.e. you don't know to write unit tests but don't put enough effort to learn the tips and tricks.  In this article, I have shared some of the most common excuses given by programmers for not writing unit tests.

1) I don’t have time to unit test.
Really? But you have to time to fix your mistakes later?   The simple fact is that nobody, not even you, can write bug-free code.   Unit tests greatly speed up the time it takes to identify a bug because they narrow the suspect code down to a very specific unit.   Other types of testing, such as Quality Assurance or User Acceptance Testing, identify problems at a much higher level, forcing the developer to spend extra time plodding through the various units looking for the root cause.

Unit tests can also serve as verification that the bug is corrected without having to go through the hassle of creating a new application build and deploying it for further testing.   Simply put, unit tests speed up overall development.   It might take slightly longer to create each new feature, but the development time for the entire application, from inception to delivery, is considerable shorter.

2) Programmers are paid to develop code, not to write a unit test or comments.
You must understand that unit tests are code. They are as integral to the application as any other piece of code you are writing and should be included in the original estimate and statement of work.  It might also help to mention to the client that unit tests lower both development cost (see the previous excuse) as well as maintenance cost.  If you are not writing unit tests, then you are doing your client an injustice by forcing them to incur extra expense.

3) I am supporting a legacy application without unit tests.
That still doesn’t preclude you from writing your own.   Granted, you are not going to be able to go in and write tests to bring the entire code base up to an acceptable level of coverage.   You most likely don’t have the time or resources to do that.   But as support issues are raised, write the unit tests for any code that you modify.

When I am working on a support task, one of the very first things I do is write a unit test to recreate the bug.   When the unit test starts passing, I know that I have fixed the problem.   Now, not only have I resolved a bug, but I have added some unit test coverage to the code base.   Over time, this coverage will become more and more robust, and actually, reduce future maintenance costs by preventing the introduction of regression bugs. suck up and fix it

4) QA and User Acceptance Testing is far more effective in finding bugs.
No arguments there.   But Unit Testing is far more effective at preventing bugs.   Just because my smoke alarm is better at detecting potential fires doesn’t mean that it is safe to leave the stove on all the time.

Both QA and UAT are smoke alarms - they alert you to potential existing trouble.   Unit testing is turning off the stove when you are done - it helps you prevent trouble.   Unit testing, QA, and UAT are all important parts of the testing process, and they each play very different roles.   Trying to replace one with another doesn’t work.  I wouldn’t release a project that was good unit tested without QA, and I wouldn’t release a project that was thoroughly QA’ed without unit testing.

5) I don’t know how to unit test, or I don’t know how to write good unit tests.
Well, this is probably the most valid excuse that is out there.   The sad truth is that a great many numbers of developers and engineers do not know how to unit test.   I didn’t when I started.   And nothing discourages a developer more than struggling to write bad unit tests.   Luckily there are resources out there.

There are so many books, webinars, conference presentations, blogs, etc on writing good unit tests that the inability to write them simply isn’t going to cut it as an excuse anymore.   When someone offers me this excuse, I don’t look at it as a roadblock, but rather as a teachable moment.

It usually only takes a time or two of seeing how well written unit tests can help one develop code to turn them from the dark side. If you are serious about learning tips and tricks of writing good unit tests then read Test Driven. It will teach you how to unit tests and how to improve them slowly.

Top 10 Excuses Programmers Gives to Avoid Unit Testing

6) QA will do testing
It’s not my job to test code – I don’t know at what stage a software developer decides that he can just throw code over the wall. If your job title was simple Coder than maybe there’s an excuse. But as your job is to develop working software, you need to be able to say that your code is functional.

7) I write GUI code
Some programmers give excuses that they write GUI code which is difficult to test and automate testing is even more difficult. Well, that's not true there are always some tools to test GUI e.g. if you are writing JSP or HTML using JavaScript, you can always test using Selenium and other similar tools. It just a matter of finding right tools.

8) Unit testing is slower and painful
It's true that if you have tons of unit tests in your project and if they execute as part of build then it will take some time but with the advent of Jenkins and similar continuous integration tools, you don't nee to worry about that. Once you make a checking, Jenkins can start building automatically and alert you if any of your existing unit test failed without you doing anything. I suggest you reading the Continuous Delivery by Martin Fowler to learn more about Jenkins and other tools.

Unit testing excuses by Programmers

9) Unit test are hard to maintain
This one is certainly a genuine point but that not good enough to deter you from not writing unit test. Many developers who even write unit tests fail to maintain them and with more modification in code either those tests are not relevant or fail, but again with the automatic build and test tools like Jenkins, you will immediately know which tests need change as part of the recent change in code.

10) Unit testing is boring
It is boring only if you don't know how to write a unit test and how to test your code, but once you know that it is the most exciting thing for a programmer. You would love to write automated tests to test your code, you will hate the traditional main() method way of testing Java code because of the flexibility and power provided by unit tests. You can use even stubs and mocks to test something which is not yet available.

These are some of the most popular excuses for not doing unit tests, I am sure you have also used one of these excuses in the past. If not, then either you are a professional, disciplined developer or simply lying. Btw, unit testing is also one of the things which separate an average developer with the superstar developer. The later one always finds innovative ways to test their code automatically and more consistently.

Further Learning
Unit Testing In Java With JUnit
JUnit and Mockito Crash Course
Learn Unit Testing with Junit & Mockito in 30 Steps


Anonymous said...

thanks for giving me this knowledge

Mohit Kumar said...

Guys Good Stuff Shared you can learn these things practically over https:\\ , Its free of cost

for further queries contact me over the same

Ada Atchinard said...

Hi! Thanks for this article. I appreciate it.
I'd like to know if there is a way to unit test reports built with Dynamic Reports library ?

Anonymous said...

0) Unit testing is overhyped
For statically strong typed language (java...) and most of the (boring, crud like) enterprise applications, the return of investment of unit testing is very low past a 10 % code coverage. Yet hipsters insist that 80% code coverage is a minimum...
So here I am wasting my customer money writing some not so useful but feel good (all the lights are green) tests...

Post a Comment