对于问题我是单元测试还是集成测试？我的回答有点挑衅：进行测试并让其他人花时间进行分类法。
对我来说，各个测试级别之间的区别在技术上是没有意义的：经常使用相同的工具，需要相同的技能，要达到相同的目标：消除软件故障。同时，我可以理解大多数开发人员使用的传统工作流程需要这种区别。传统工作流程让我感到不舒服。
因此，我的问题旨在更好地理解对我来说有争议的事物，并收集各种观点来探讨各个测试级别之间的这种分离是否相关。
我的观点不对吗？是否存在其他不强调这种分离的工作流程（可能是敏捷方法）？您在这个问题上有什么经验？
精度：我完全知道这些定义（对于那些定义不正确的人，请参见此问题）。我认为我不需要关于软件测试的课程。但是，如果您的答案需要，请随时提供一些背景知识。
我必须同意@Alex B，因为在编写测试时需要区分单元测试和集成测试，以使单元测试尽可能快地运行，并且没有比测试单元依赖更多的依赖项。测试代码。您希望单元测试非常频繁地运行，并且“集成度”越高，就像它们运行的次数越少。
为了简化操作，单元测试通常（或应该）涉及模拟或伪造外部依赖项。集成测试有意地保留了这些依赖关系，因为这是集成测试的重点。您是否需要模拟/伪造每个外部依赖项？我不一定要说如果模拟/伪造的成本很高并且返回的值很低，那就是使用依赖关系不会显着增加测试的时间或复杂性。
尽管如此，总的来说，最好是务实而不是教条，但要认识到差异并避免混淆，如果您的集成测试使它过于昂贵而无法频繁运行。
So a pragmatic separation would be between frequent fast tests and unfrequent slow or complex tests? I’ve already encountered unit tests which needed heavy hardware to be run (a switch off sequence observed with a logic analyzer plugged on the CPU bus for instance).
– mouvicielFebruary 05, 2009 21:20
If I understand correctly, you build your test groups according to how fast they are and how many times you run them. I think this is a good point, thank you.
– mouvicielFebruary 05, 2009 21:26