DotNetCurry Logo

12 Unit Testing Myths and Practices

Posted by: Eli Lopian , on 1/27/2015, in Category Patterns & Practices
Views: 25225
Abstract: This article presents the most widely misunderstood concepts about unit testing today and provides relevant information about how the practice actually occurs.

Unit testing, though widely implemented these days, can be a little misunderstood. From developers who don’t yet see the advantages, to project managers who aren’t convinced of it’s worth; unit testing still has its skeptics. In the following article, we’ll take a look at some of the myths regarding unit testing and some of the most commonly implemented practices as they relate to these myths.

 

Myth 1: It makes changes more difficult to make

Not only is this false, it’s in fact the opposite. One of the biggest benefits of doing unit testing is the ability to implement large changes and immediately check that your changes have been done properly. Making changes and then later realizing that it’s affected other parts of your software, and then trying to isolate what caused the issue, is what not only makes changes difficult to make, it also causes developers to be wary of making changes.

In practice: Unit testing makes changes easier to make and lets developers refactor without fear. Again, again, and again. The ability to make changes is one of the biggest reasons people choose unit testing.


Myth 2: It slows down the development process

Running unit tests might initially make the process seem slower, but the reality is that it saves time by preventing mistakes and recognizing them before the process goes too far. Furthermore, it allows developers to have more confidence in the work they’ve already completed, thus clearing the way for progress. And throughout the life of the development process, the advantages of using unit testing can result in spending less time.

In practice: Like any new tool, it takes a little while to get used to, but on the whole, using unit testing will save you time and cut down on wasted time. In fact, regression testing will keep things moving forward without having to worry too much. Running tests during your regular builds means it doesn’t take away from development time.


Myth 3: It disconnects the developers from the code

This is just plain wrong. It’s the developers who will have to help design the testing process, which means that they’ll have to delve even deeper into the functioning of code and take more responsibility for its functioning in smaller units, as a part of a whole program. Sometimes it’s easy to lose sight of functions and procedures while looking at the entire program, but with unit testing, it’s a given that these won’t be overlooked.

In practice: Using unit testing, compared to other approaches, requires developers to understand not only the code and what it’s supposed to be doing, but also the various conditions, inputs, and outputs that could affect its functioning that they might not notice under other testing conditions. More functions and procedures receive individualized attention when using unit testing.


Myth 4: It makes documentation more difficult

Unit testing does not make documentation more difficult, but it can make it more detailed, which isn’t such a bad thing. Nobody really loves documentation, but unit testing doesn’t make it any more intrinsically arduous. Developers find that documentation when using unit testing is easier to do, when documentation is reflective of the procedures and functions isolated within unit testing.

In practice: Repeat the structure and divisions from unit testing in documentation and you’ll not only have higher quality documentation, it will be much easier and pleasant to do. Some developers use product roadmaps as inspiration in the creation of unit tests, knowing that the same can also serve as a framework for documentation.


Myth 5: The work gone into making unit tests is wasted once the project is finished

Totally untrue. If you’ve ever reused code, you’ll know that anything you work on, becomes an asset.

In practice: When you take code you’ve done for one project and edit it for another, you can take the same unit tests and edit them as well. Using snippets for similar tests within the same project is no problem either.


Myth 6: It’s a waste of time

You know what’s a waste of time?

· Fixing the same bugs over and over

· Writing and rewriting proofs throughout the development process

· Fixing one bug, only to have another one magically appearing somewhere else

· Getting interrupted in the middle of coding and completely losing your way.

Resistance to unit testing is understandable, but many developers come around to extoll its benefits once they complete a project with unit testing.

In practice: You only have to write a unit test once and can execute it as often as you want, independent of any other code changes you’ve made. Your initial time investment will pay off in the long run.


Myth 7: But it’s such simple code, why write a test?

It seems simple, until something goes wrong. And then things aren’t so simple any more. There’s no doubt that writing a unit test, even for simple code, adds stability and security to a project.

In practice: Simple code requires a simple test, so there are no excuses.


Myth 8: You only need unit testing when there are many developers

While it is a good policy to utilize unit testing when there are many developers, not using unit testing because there is only one developer is definitely a mistake. All the benefits of unit testing when there are groups of developers are also bestowed on single developers.

In practice: Unit testing can help a one-person team just as much as a 50-person team. And from an assets protection perspective, it’s even more risky to let a single person hold all the cards.


Myth 9: It doesn’t help debugging or prevent bugs

Absolutely untrue. Unit testing makes debugging much easier because you can focus on the part of the code that is problematic, fix it, and then reintegrate it. It also prevents bugs from occurring as features are added, a problem that is persistent and immensely frustrating, particularly when using OO programming. It’s not a 100% guarantee against bugs, but it’s a good way to reduce instances.

In practice: While unit testing won’t solve all your debugging problems, the isolation of code can make fixing them much easier once you find them. One of the biggest benefits to using unit tests, according to developers who are big fans, is that it makes debugging significantly easier and simpler.


Myth 10: Unit testing makes you code differently

Code differently? Yes. Code better? Yes. Developers who rely heavily on global variable and singletons will find that their code is tightly coupled. In order to do any kind of testing, code needs to have loosely coupled data, which is just not how singletons work. Coding with global variables and singletons is not the optimal way to work most of the time. If testing is the reason why your developers change for the better, then why not?

In practice: The biggest benefit to using singletons is to solve the problem of resource contention, which you’ll probably only face in rare instances, like when dealing with a log. In other cases, it’s just an old habit with few benefits that makes code extremely difficult to test.


Myth 11: Debugging isn’t complete

Just because you don’t have to run through the entire sequence of code to debug, doesn’t mean that it’s incomplete. Debugging with unit testing is just as, if not more, effective than other types of debugging. In fact, unit testing has a clear advantage in greatly reducing, if not eliminating, the amount of returning bugs as I mentioned above. Recurring bugs are one of the most frustrating things while developing and testing a program. By unit testing, you can reduce the frequency of new bugs as you add, edit, and remove features. Debugging is never “complete,” particularly when the program will run on devices or systems with significantly varying specs.

In practice: Unit testing, when solving bugs in particular, is almost a guaranteed way to see that those bugs will never return. And when you’re debugging, you won’t have to go through an entire sequence of code just to edit the buggy parts.


Myth 12: Unit testing increases development costs

One thing that can bring even the best developers to tears is a request for changes. Project managers, CEO’s, CFO’s, and other executives are working hard to make your project profitable, throwing out ideas and then figuring out development costs later. In a truly sincere effort to bring profitability, managers and executives can demand huge changes immediately or decide to throw out months of work because it seems that they’ve discovered there’s no market for that feature. Executives want a product that succeeds financially and sometimes that means major changes or making an enormous pivot quickly.

In practice: By decreasing the difficulty of implementing large changes, developers can be more flexible to the needs of the product itself, thus increasing chances for financial success. And while writing beautiful code that executes flawlessly is awesome, it’s even better when it’s financially rewarding.

Although there are a lot of misconceptions about unit testing, it’s still a very highly regarded practice that’s necessary to your software testing efforts. These were the 12 biggest myths and their coinciding best practices for unit testing; hopefully you can use these practices to unit test more effectively in the future.

Was this article worth reading? Share it with fellow developers too. Thanks!
Share on Google+
Further Reading - Articles You May Like!
Author
Eli Lopian is the Founder and Head of Products & Technology at Typemock. He enjoys a white board, code and transforming developing environments. Secretly his one true love is Unit Testing and he has dedicated his life to making unit testing easier for everyone else. Eli frequently posts on his blog regarding innovative concepts, advanced development techniques and testing methodologies.


Page copy protected against web site content infringement 	by Copyscape




Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by zonray on Friday, January 30, 2015 12:27 PM
Myth 12 makes a lot of sense. Thanks.
Comment posted by Satya on Tuesday, February 10, 2015 12:12 AM
Isn't this the same as Extreme Programming? What's the difference! Also where do you cover refactoring in the SDLC cycle?