Home > Uncategorized > 10 Reasons to Write Unit Tests

10 Reasons to Write Unit Tests

It’s been bothering me for quite some time not being able to explain the people out there why they need to write unit tests. The most common responses that I got were “this is a waste of time” and “my application has no bugs”. Unfortunately, this overconfidence and cutting corners is hurting the developers (and the industry).

I compiled this short list of why I write unit tests:

  1. Don’t let your customers discover embarassing bugs. Write tests to cover a multitude of scenarios and catch these bugs before they get into production.
  2. Test complex scenarios quickly, without having to manually reproduce them in the application.
  3. By testing often, you don’t break the application as you go. You can’t always know the indirect implications of what you’re writing, especially if you didn’t write the original application.
  4. By testing early, you don’t write unnecessary code but only the strict necessary. This makes the codebase smaller and more maintainable. It also saves on development time.
  5. You do not have to debug the same code twice. Once you have a test to account for a possible bug, you’ll pick up any wrong turns quickly.
  6. You ensure readability. A unit test makes the purpose of your code easier to understand.
  7. You ensure maintainability. Unit-testing forces you to better encapsulate functionality, thus making it easier to maintain and add new features.
  8. Refactor without worries. Run the tests to make sure everything still functions as intended.
  9. Save time on testing. You can test the entire application at the speed of your CPU.
  10. Feel safer. How many times were you afraid to add a new feature or change something in your application’s core? No more!
  11. Bonus: know exactly what is broken. Instead of hunting for an obscure bug, let the tests tell you what’s wrong and why. Example: the application will tell you when you add an item to a cart but the cart still appears empty. It will also tell you what item you tried to add for the cart to break.

You may have different reasons, so share them in your comments.

Tags:
  1. May 31st, 2010 at 20:28 | #1

    As a corollary to 5, you can actually code a test to demonstrate a bug, fix it, and then leave it in your test suite so you guarantee you don’t ever re-introduce a bug.

  2. June 1st, 2010 at 16:02 | #2

    Sweat
    I totally agree with you.

  3. June 2nd, 2010 at 08:07 | #3

    Very interesting but, i could be fine to explain the best way to write unit tests…
    or may be listing existing tools (ex: PHPUnit…), or library… or just explaining how to do it.

  4. June 2nd, 2010 at 23:12 | #4

    I choose PHPUnit for my unit testing needs. The project is thouroughly documented.

    Here’s a solid introduction by Sebastian Bergmann: http://www.slideshare.net/sebastian_bergmann/testing-php-applications-with-phpunit-3-8227

    I know that his company offers trainings. He can explain good test writing better than I can.

  5. June 3rd, 2010 at 10:36 | #5

    Anna,

    You’ve given me another clue bat to swing around, unfortunately some people are… *carefully choosing my words here* …finding excuses not to unit test. Maybe this simple overview will help me convince them to rethink their current opinions.

    Thanks.

  6. June 4th, 2010 at 09:14 | #6

    These are very good points made. The notion of resisting unit tests in development is also rooted in a lack of experience or acknowledgment that software if defect prone and is costly, no matter how expert the developer. I tried to lay out some point for unit testing in my post. Please see below:

    http://assarconsulting.blogspot.com/2009/10/perils-of-not-unit-testing.html

  7. June 4th, 2010 at 21:39 | #7

    I agree that Unit Tests are very useful, and these are things that Unit Tests might help with.

    However, I think you are talking about Automated Testing in general, not Unit Tests.

    Unit Tests are intended to test the smallest units they can get a hold of. This leads to the use of mocking and stubbing. When the assumptions of one unit change, the mocks/stubs of it used elsewhere do not. The code that uses these mocks/stubs still makes out-of-date assumptions.

    Without other forms of testing, such as Functional Testing which tests larger integrated pieces, you actually will not catch many bugs with your test. Worse, you’ll be more prone to them because you’ll feel safer than you really are.

    I talk a little bit at my blog about what Unit Tests do and do not do:
    http://codequirks.com/2010/05/27/why-failing-tests-make-refactoring-safe/

    More on that topic will be coming soon.

  8. June 9th, 2010 at 08:23 | #8

    I agree that functional tests are also necessary. I could not live without these.

  9. Ashay
    October 27th, 2010 at 11:47 | #9

    While I agree that unit tests and functional tests are required, I more of a proponent of test first programming. Not only does it force you to think thru the functionality to be coded, it also helps validate that the test will fail when it needs to and then one can also see if sufficient failure information is being captured for the inevitable triage/debug.

  1. No trackbacks yet.