I think the key here is that a lot of folks just write bad tests, and they write code that is hard to test.
Part of the point of TDD, as I understand it and I am fairly new to this whole world so I am happy to be debated on the topic, is that if you're getting pain from writing your tests then it should cause you to think on how you're writing your code, and the structure of what you've built.
So, people who only have bad experiences with tests will often be aggressive about how much they loathe them and how over-rated they are, because they experience brittle slow frustrating tests. People who use (like it says in TFA) dependency injection, loose coupling and write tests that aren't tightly coupled to implementation details - their unit tests only test one unit of code for example - and make good use of mocking and stubbing, have happier experiences with testing and for those folks the more tests and better actual coverage (not just a number reported by an algorithm) the happier they are.
...and never the twain shall meet.
When I started out learning to code again, a few years back, after a decade or two gap from my BASIC/FORTRAN days during my Physics degree I hated testing. It was hard. It was a waste of time. It just frustrated me. It took me a long time to learn to write good tests and to write good code that was, it turns out, much easier to test. This is an under-documented area, with nowhere near as many online resources as there are for just slinging code. But it's worth it. IMHO
Part of the point of TDD, as I understand it and I am fairly new to this whole world so I am happy to be debated on the topic, is that if you're getting pain from writing your tests then it should cause you to think on how you're writing your code, and the structure of what you've built.
So, people who only have bad experiences with tests will often be aggressive about how much they loathe them and how over-rated they are, because they experience brittle slow frustrating tests. People who use (like it says in TFA) dependency injection, loose coupling and write tests that aren't tightly coupled to implementation details - their unit tests only test one unit of code for example - and make good use of mocking and stubbing, have happier experiences with testing and for those folks the more tests and better actual coverage (not just a number reported by an algorithm) the happier they are.
...and never the twain shall meet.
When I started out learning to code again, a few years back, after a decade or two gap from my BASIC/FORTRAN days during my Physics degree I hated testing. It was hard. It was a waste of time. It just frustrated me. It took me a long time to learn to write good tests and to write good code that was, it turns out, much easier to test. This is an under-documented area, with nowhere near as many online resources as there are for just slinging code. But it's worth it. IMHO