I have a similar feeling towards TDD. I use test driven developments for those parts of my code that needs it. I recently had to create a function that did some complex calculation. TDD was great for that, because I had a set of known inputs and a set of known outputs. It made sense to write the test before the code.
But I will not write trivial tests just to make the unit test coverage increase. I've seen tests written for simple getters/setters that just sets "this.birthday = date". If we do contact an alien civilization that have multiple birthdays, we will probably have to change the code anyway and the unit tests will have to be rewritten.
I may get some negative votes for saying this, but whenever I see a project with 100% unit coverage it's a red flag for me. This means they have wasted a lot of development time while writing trivial unit tests for trivial code.
Unit tests are great for parts of the code that needs them. But if your only reason for writing a unit test is to see the statistics "improve", you are wasting effort.
I agree with you about getter/setter and trivial code. But sometime when you're a VP of Engineering and you knew that most of your developers will slack off eventually and start not writing unit-test guess what you'll do?
You set the code coverage bar high enough.
While I disagree with the said VP or Lead or Senior people, but sometime we have to admit that not many developers in our industry care about quality and have the attitude of test is important.
I get that shipping is more important than anything else. But I found people often use that excuse for not writing test. Besides... the definition of "Done" pre-TDD/Agile is "I wrote my code albeit not thoroughly tested, now let me throw this pile of crap over the wall to the QA".
It's just how our industry used to work until recently.
A good reason to write tests for seemingly trivial code like that is if you're implementing an API that others will use. I've re-factored a class that implemented a public API and been saved by trivial tests that pretty much just tested getters/setters.
But there's a time and place for everything. I rarely pass 95% test coverage, the remaining 5% are usually not worth pursuing.
If you're using tests to check your API integrity, ok, but writing tests by hand for getters and setters written by hand would be disgusting. Hopefully a very minor declaration in the code can automatically create all the tests.
I feel this is the responsibility of an audit system and not the code itself. I have never understood why people write code to verify a contract when it should be done as a rule in a proper SCM system.
A better process is to write or purchase plug-ins for your SCM system that audit all commits and either notify of a contract violation or refuses commit without a supervisors override. Enforcing contracts is not the domain of custom code it is the domain of SCM and therefore should be implemented at an SCM level. This way you write it once and everyone benefits whereas with test you are a. writing test for every contract and b. leaving in the hands of the current developer to ensure the contract is met. Further by having it audited you can build a process around that audit to guarantee that the issue is accounted for.
I am not sold on TDD, but I have not thrown it out as snake-oil yet either. It is in no way the harbinger of quality it was heralded to be, but logically there are some places that it seems like it can and does help but my general feeling about it in the way that it is sold (test everything), is that it is a wast of time.
Having 100% test coverage for a product that nobody wants is a waste of time, while having 0% test coverage for a product that many people are using is dangerous.
The challenge for a startup is finding the right balance between the two.
But I will not write trivial tests just to make the unit test coverage increase. I've seen tests written for simple getters/setters that just sets "this.birthday = date". If we do contact an alien civilization that have multiple birthdays, we will probably have to change the code anyway and the unit tests will have to be rewritten.
I may get some negative votes for saying this, but whenever I see a project with 100% unit coverage it's a red flag for me. This means they have wasted a lot of development time while writing trivial unit tests for trivial code.
Unit tests are great for parts of the code that needs them. But if your only reason for writing a unit test is to see the statistics "improve", you are wasting effort.