If your application is so large, it would be good to ask first if it really needs to be so. We favor small methods, which do only one thing. We favor two pizzas

If your application is so large, it would be good to ask first if it really needs to be so. We favor small methods, which do only one thing. We favor two pizzas teams, which are small. Why large applications are not considered harmful? You might want to move some of your functionality into different modules, libraries or separate applications. The false premise lying behind the 100% coverage philosophy is that instead of avoiding bad practices and being careful with your every step, trying to make things as obvious as possible, tests let you not to think about it. You can stop worrying. They work like a committee, freeing you from responsibility. Especially if you're a mediocre programmer looking for constant excuses. Articles about tests are mostly abstract. Kool-Aid's hectoliters why tests are great, yet nearly zero discussion how to get them right. Tests are not created equal. I follow Rails blogosphere, which is a very test oriented community, and I don't remember too many, if any, writings about how to write good tests. For instance, let's raise confirmation bias again. People usually write tests to make sure the things work as they think they should. I've not seen too many agressive tests that tried to check exteme cases, to, literally, falsify the method. If you deal with things more complicated than Rails controllers, it becomes the real issue. I also try to perceive tests in terms of ROI. If you don't plan to make your application big, why bother? If you don't plan to do any non-standard things, why bother? If it took five minutes to come up with an immediate and obvious solution, why bother? If you change your frequently ("writing is rewriting"), why bother right now? I'm not saying that tests are all bad. I just don't get the whole hype, saying "write tests, be happy" without raising all risks involved.