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.
7
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.
3
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.