So the worst of us developers out there write tons of tests? We wish. Who cares if it's 80% or 100%, i'd rather inherit a codebase with lots of test coverage than without.
Test coverage is a plus but not more important. We have an end to end test system that runs on each commit. What I am saying is perfect code, simply written is way way more important than complete coverage. Tests, on my experience, don't make code better written or more concise. Given a choice between coverage and good code I choose good code. In my experience time is always short so I choose the time on good code. In practice this is a compromise anywhere but the most cashed up companies.
If I am understanding correctly, he is saying that well-written code requires fewer tests in order to be fully tested. Fully tested is better than untested, assuming that code is fully tested, well written code will require fewer tests.
That is my understanding, as it is rather hard to extract a solid argument from his posts.
He specifies "any tests", as do several other anti-test posts in this discussion, though often someone will reply to them and assume, like you have done, that they have another complex set of automated tests that they're happy about, and they're only railing against some unspecified subset of automated tests. I'm not sure if that's being over-charitable or not.
Oh I completely agree, and would much rather be working on a codebase with too many unit tests than too few. I'm trying to come up with the most charitable explaining that I can.
And what about test coverage for the tests? You do realize that tests are also code, right? They have bugs, maintenance overhead, and all the other things code has.
The worst code bases I've seen have more test code than code being tested. People try to write tests to cover every condition or input and in systems of even modest complexity that isn't possible, or at least not feasible in a finite time.
The actual code is the check on the tests. They cover each other, acting as though they are and there is some infinite recursion dishonest.
Tests do have a maintenance cost, but it is much lower than the maintenance cost of code without tests. Without manual tests if there a bug it must be caught manually, this costs human time every time the tests are run. That also presumes the humans do the tests correctly, have a new team, QA person out sick, what is the cost now?
The cost of not having tests is bugs in production. If I write code and there a bug that impacts production many millions of dollars are on the line, and this is true for many developers. Write software for any airplane? Crashes can causes crashes so they are dangerous and expensive. How about something more common, Write software software for an online store? If the shopping cart drops 1 in 1000 items that is a huge amount of money, not just because of lost sales, but also angry customers. You will want to run the tests at least a few thousands times to catch that, a human won't do this, an automated unit test suite is shell script and VM away from doing that.
Automated tests don't make this impossible but it reduces the amount of bugs that can make it through. If a test costs 10 hours of developer time at $500/hour and stop one bug that would have alienated 1% of customers. Then there would only need to be 500,000 customers worth $1 each. Clearly these numbers have insanely inflated costs, yet they still make sense for many businesses. And this is only accounting for one bug. Finding that bug did not consume the test, it is still ready for more. A good test can many bugs and last many years.
I don't disagree that tests are good and necessary. I take issue with the view that tests are somehow free, that more testing is better, or that tests are of such marginal cost that more effort developing tests than the product is considered a reasonable use of resources.
Also, the notion that "they test each other" is likely to be dangerous.
> Also, the notion that "they test each other" is likely to be dangerous.
About as dangerous as double entry bookkeeping. Of course it doesn't provide any absolute guarantees, but having people state things in multiple contexts and checking their consistency is one of the better approaches we have for finding errors.