Unit tests and TDD should be used as tools when necessary. Unfortunately, many team leads and higher-level engineers don't take the time to explain to juniors w

Unit tests and TDD should be used as tools when necessary. Unfortunately, many team leads and higher-level engineers don't take the time to explain to juniors when to use these tools. Just that the tools are essential. And therefore, for many engineers, they have become a religion, or worse - a cargo cult. But really, most code does not need to be tested. The parts that are likely to break when others change them should be. Testing can mitigate risks for complex, esoteric, highly dependable, domain-specific, and technical code. In such cases, tests can save a lot of time that would be spent fixing defects later. In contrast, testing as a religion is entirely counter-productive. It's a time sink in an effort whose whole purpose is to save time. And what is worse, poorly written tests make the codebase less maintainable, more complex (to pass wrongly written tests), and degrade code quality (through a false sense of security). Functional/integration testing can suffer from the same problems. There's nothing more annoying than fixing a defect in a system only to uncover a mess in functional tests that relied on the bug. Of course, some of this is unavoidable. However, cargo cult-style testing is avoidable and entirely self-inflicted harm in many teams. In short: testing is a tool to save time and increase code quality; such a tool should be used where it saves time and improves code quality, and it should not be used where it just results in the opposite.