Unit Testing Disadvantages
Unit Testing strength have a lot of advantage for the long run, however we must also be aware of a few disadvantage of Unit Testing :
1. Time Consuming
This is one of the most mentioned as a disadvantage. Creating a unit test does take more time, because developers must set aside time to actually write the unit testing code. Some people put it at up to 30% more time.
From a busy development team’s point of view, the biggest disadvantage of taking on unit-testing is the initial time required to develop them. It’s been estimated that it takes approximately 30% more time at project start up to begin putting unit-tests into place. That’s a significant commitment of resources and in many teams with tight deadlines to meet – it’s a big deterrent to implementing unit-testing.
Now, 30% is a lot of time investment. Unit Testing is therefore not suitable for small projects.
2. Adding more complexity
Naturally, with more code comes more complexity. Also, considering that Unit Testing have mocks and stubs that must be created, it creates additional level of complexity.
Honestly, all of these are true and they have their proper place in development, but the fact is that unit testing is additional code and additional code always introduces more complexity. As such, we have to make sure that we have a proper way to manage and organize all of our unit tests.
3. Steep Learning Curve
Unit Testing is tough to implement, especially together with Test Driven Development. A lot of articles and tutorials out there deals with the benefit of unit testing, but very few actually write clear examples of unit testing in action.
Many developers seem to expect that they can be efficient with test-first programming right from day one. Unfortunately it takes a lot of time to gain experience and program at the same speed as before. You can’t get around it.
To be more specific, it’s very easy to get wrong. You can very easily (with very good intentions) end up writing a whole bunch of tests which are either difficult to maintain or testing the wrong stuff. It’s difficult to give examples here – these kind of issues simply take experience to solve. You need to have a good feel of separating concerns and designing for testability. My best advice here would be to do pair-programming with someone who knows TDD really well.
4. Under coverage or Over coverage of Code Base
Now, depending on your skill levels , it is possible to either go under coverage of the code base or over coverage of the code base. While the best practices suggest to limit unit testing to test functionalities, people who follows TDD tend to over do it, while those who are forced to do TDD do not cover everything.
Writing tests so that you cover everything (100% code coverage)
Ideally, again, if you adhere to the methodology, your code will be 100% tested by default. Typically, thought, I end up with code coverage upwards of 90%. This usually happens when I have some template style architecture, and the base is tested, and I try to cut corners and not test the template customizations. Also, I have found that when I encounter a new barrier I hadn’t previously encountered, I have a learning curve in testing it. I will admit to writing some lines of code the old skool way, but I really like to have that 100%. (I guess I was an over achiever in school, er skool).
Personally, I found point number the hardest. Despite writing several articles on unit testing, I have yet to write a unit test beyond the tutorial examples. It looks like a very big obstacle. And with the everyday problems we encounter, it is easy to push Unit Testing to the sideline.
What is your biggest problem with Unit Testing ? Please share in the comment below.