Let's get some things straight first. People are not even qualified for stating their argument if they
- Have not maintained over 40% useful and valid test coverage on software that's went live and been maintained for months if not years. These people do not even really know what unit testing is. They never even done it themselves.
- Have not overseen a team to ensure proper test coverage across all the code base. It's an uphill battle that some people never faced. Slipping is easy while rising is hard.
- Do not know how to calculate test coverage for the language they use. Yes to point 1. Yes to point 2. 40% coverage by eye balling the code? Hilarious.
- Do not know the basics of a "good" unit test; AAA, A-TRIP. They never even experienced the benefit of true proper unit tests. They don't even know how to identify a pile of spaghetti tests that is make their life hell on earth.
I can quite safely say that above alone rules out 95% of people I mostly argue with. Yes I'm been overly generous. I'm a generous person. They argue with me blue to the face when they never did it themselves and they can't actually do it themselves. Yes they talk and act like they know all about it.
With that out the way, we can now have some proper intelligent discussion.
The code is simple and straight forward and it doesn't need tests
And we have a "code simplicity o' meter" that gives the code a score between 0 and 100 with 25 been the "complex code threshold" that requires tests? Simple code will have simple tests. If it's so straight forward that it doesn't need test, writing one wouldn't take more than a few minutes. If it does take more than a few minutes, then either:
a) the code is not as straight forward and simple as it was perceived or
b) the programmer don't know how to write unit test in which case it's a good practice anyway.
(Yes I'm aware of CCM and I use it myself. People who argue this "simple code" thing with me doesn't know about it usually though, so shhhhh.......)
The code is too complex and writing test takes too much time
Ensuring correctness to subtle mistakes in complex code is one of the main points of unit testing.
Unit Test cost extra time / money
I'd like to say I never have problem burning through same number of points in a sprint as people who doesn't write tests, but I can accept the cost factor to tests thing. At this point, it becomes a complex debate.
- Why can't the business afford the time / money to write these tests? Writing the actual code is only a small part of the development cost. If the margin is so low that an extra 20% (arbitrary number) increase of 50% of the project cost can't be paid up front that has long and far reaching benefit, maybe there isn't even a business model to begin with.
- Or does it. It is a fact that the earlier an issue is fixed, the less costly it is. Unit test is the second quickest feedback mechanism, behind compilers. If a regression can be stopped at unit tests, it cost far less than one even in staging/UAT environment where resetting environment can cost a lot of time and sometimes money.
Then, from the hot shot developers.
I don't make mistakes and I haven't made one in X years.
But others do, and they will come change your code. Deal.
And lastly,
Code base is still changing. Time we spend writing test could be a waste.
Do or do not, there's no try. If the code you are writing is not going to be run or used, why you even writing it? If yes, even a simple client proof of concept application crash can potentially lose you the deal. Any production code needs tests. Period. As for those so called prototype / throw away code. How cute, when's the last time that happened; throwing away code.
