5

To write Unit Tests we have to write extra bits of code. For several projects we do Unit Tests and for several projects we do not.

As a Team Leader I face trouble to make the right decision.

Is there any or list of terms by which I can take the right decision whether we will do Unit tests or not?

EDIT: Please provide a comment while down voting the question. It will help me to improve my question.

Md Mahbubur Rahman
  • 4,747
  • 5
  • 32
  • 38
  • 9
    if (isWritingCode) { writeUnitTest(); } – Anthony Pegram Feb 07 '13 at 16:57
  • 3
    Robert C Martin once said : "What if you were on the Starship Enterprise and the warp coil was seconds away from an anti-matter explosion and all you needed to do was invert one IF statement to save the ship. Would you use TDD for that?: **Yes**." http://blog.8thlight.com/uncle-bob/2012/01/11/Flipping-the-Bit.html – Laurent Bourgault-Roy Feb 07 '13 at 17:18
  • @LaurentBourgault-Roy If the warp coil is _seconds_ away from an explosion, it's bye-bye Enterprise either way :P – Andres F. Feb 07 '13 at 17:24
  • @LaurentBourgault-Roy, +1 to your excellent comment. :) – Md Mahbubur Rahman Feb 07 '13 at 17:26
  • 1
    Ugh, unfortunately Uncle Bob has lots of fundamentalist, extremist assertions such as "I want you to believe that Test Driven Development saves time in every case and every situation without exception amen." Yuck, talk about an unhelpful assertion. – Andres F. Feb 07 '13 at 17:28
  • @Andres F. I agree with you comment, but I like the philosophy. In this case I will admit, I will not unit test my code because I just won't have the physical time :) But generally, I like the idea to always write unit test unless you have a very good reason not to. – Laurent Bourgault-Roy Feb 07 '13 at 17:37
  • 3
    I closed this as Not Constructive, but it essentially a duplicate of this same question on Community Wiki... http://programmers.stackexchange.com/questions/158052/are-unit-tests-really-that-useful/ – maple_shaft Feb 07 '13 at 18:31

2 Answers2

8

As a rule of thumb I would argue that you should write unit tests for all code you write. There may be cases where you don't need to unit test something, but I would have thought these would be unusual and unlikely.

The advantage to having tests for your code is you know when some functionality changes, of course you need to have good coverage and well written tests that you have confidence in. Just having a test cover some code isn't a guarantee that your code is correct / flawless. In fact a bad test can be worse than no test at all. But that's really a different question.

I pity the fool who doesn't write unit tests
any tests are better than zero tests. And isn't unit testing just a barely more formal way of doing the ad-hoc testing we've been doing all along? I think Fowler said it best:

Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead. I encourage developers to see the value of unit testing; I urge them to get into the habit of writing structured tests alongside their code. That small change in mindset could eventually lead to bigger shifts like test-first development-- but you have to crawl before you can sprint.

Community
  • 1
Simon Martin
  • 1,006
  • 8
  • 18
  • Unfortunately the rule of thumb lacks real world nuances. For example, it's not always a good idea to write unit tests for GUI code. Or anywhere else the costs of maintenance outweight the benefits. – Andres F. Feb 07 '13 at 17:27
  • 3
    I'd argue it *is* a good `idea` to write tests even for UI code. It may be hard to do, but that doesn't make it a bad idea. In those cases breaking out into integration tests (selenium, watin or whatever). If it's possible to follow some MV* pattern it becomes easier... and still worthwhile attempting. Your point about maintenance of tests *is valid* though, but again that may indicate a need to refactor. As with any code decision the rule of thumb applies most of the time, but not always all of the time – Simon Martin Feb 07 '13 at 17:31
  • I know what you're saying. But imagine this: I assume you realize 100% coverage is unattainable; imagine someone else saying "well, it's only a rule of thumb, but you should strive for 100% coverage whenever possible". But it's not that easy! 100% coverage might get in the way of actually delivering features. So it's _not always_ a good idea to spend time on it. Same with actual unit tests. Maybe the cost of maintenance is too high for everything to be unit-tested; maybe you should focus on the portions that merit unit-testing. Same for TDD (regardless of what Uncle Bob says). – Andres F. Feb 07 '13 at 17:39
4

The Way of Testivus says thus on the matter of when to write unit tests:

The best time to test is when the code is fresh

Your code is like clay.
When it’s fresh, it’s soft and malleable.
As it ages, it becomes hard and brittle.

If you write tests when the code is fresh
and easy to change, testing will be easy
and both the code and the tests will be strong.

The key thing to take away form this is that you write code early in the process when you can still think about what the code is doing. When doing this, you think about what is testable and what isn't. Another bit from the Way of Testvius...

Think of code and test as one

When writing the code, think of the test.
When writing the test, think of the code.

When you think of code and test as one,
testing is easy and code is beautiful.

One thing that I like about The Way of Testivus rather than more dogmatic statements is it specifiably calls out dogma and says don't get stuck on it. Writing the test is more important than following rules set in stone.

Write tests.
Write tests early.
A poor written test is better than no test.