问HN：在单元测试上应该投入多少重视，以及何时进行？
我在想是否发生了某种变化。当我十多年前刚开始做初级软件工程师时，我学习了单元测试、集成测试和系统测试。我们所工作的整个代码库都经过了彻底的单元测试，并且有多层的集成测试和系统测试。我在其他公司工作过，在某些情况下，任何形式的自动化测试完全缺失。然而，当我阅读并跟进最佳实践时，得到的信息是：对所有事情进行单元测试！
我个人发现，当系统的架构尚不成熟时，单元测试可能会造成阻碍，甚至非常严重。在这种情况下，包括在完全没有测试的情况下，集成测试或系统测试来验证行为似乎是一个更好的起点。
我最近读到一个观点，建议放弃严格的“对所有事情进行单元测试”的思维方式，转而进行集成测试。我认为这可能取决于你所工作的系统类型、系统的成熟度、工程师在自动化测试方面的经验等因素。
我很想了解在什么情况下每种类型的测试对你有帮助，什么情况下又会造成阻碍（以及它阻碍了什么）。
查看原文
I'm wondering if a shift has occurred. When I started as a junior software engineer, over a decade ago, I learned about unit testing, integration testing, system testing. The whole codebase we worked on was thoroughly unit tested, and had layers of integration tests and system tests as well. I've worked for other employers since and in some cases any kind of automated testing was completely absent. Still, the message I got when reading and keeping up with best practices was: unit test ALL the things!<p>I've personally found that when the architecture of the system is not mature yet, unit tests can get in the way. Terribly so. Integration tests or system tests to assert behavior seem the starting point in this and other scenario's, including when there are no tests at all yet.<p>I've recently read a statement about letting go of a strict "unit test everything" mindset and go for integration tests instead. I'm thinking it probably depends, as with everything, on the type of system you're working on, the maturity of the system, the engineers' experience with automated testing, etc.<p>I'd be interested to learn when each type of testing helps you and when it gets in the way (and what it gets in the way of).