There's actually a section of this where he basically says that a test that always passes is not useful (provides no information) and a test that fails sometime

There's actually a section of this where he basically says that a test that always passes is not useful (provides no information) and a test that fails sometimes is useful (provides lots of information.) I'm not sure exactly what failure of reasoning lead to this conclusion but it's totally bogus. They are both useful. The ideal case is that your codebase is entirely made up of code that never fails and tests that always pass. Obviously sometimes you are going to have tests that fail and introduce bugs that cause tests that used to pass to fail. But that's the reason that you write those tests, to find those problems. The author gives the silly example of a method that always sets x to 5, and a test that calls it and makes sure x is now 5. That seems like a bad test but anyone who's actually done work as a developer understands why it isn't. If you skip the tests that are simple and straight forward and seem like a waste of time and only write more complicated tests then you will have a hard time reasoning what failed when the complicated test fails. Was your x = 5 method faulty? You don't think so but you don't have proof since it wasn't tested. Having the test, as silly as it seems, lets you know that method is working. Anyone who has been on a team that skips easy/simple tests knows what a mistake it is. And if you don't, you will eventually.