我在一个已经做了一段时间敏捷的办公室工作。我们使用 Scrum 进行项目管理，并融入 XP 的工程实践中。它运作良好，我们不断吸取教训并完善我们的流程。
我想告诉您我们通常的测试实践，并获得有关如何改进的反馈：
TDD：第一道防线 我们对单元测试非常虔诚，我想说我们的开发人员也有足够的经验来编写全面的测试，并且总是用模拟隔离 SUT。
集成测试
对于我们的使用，集成测试与单元测试基本相同，只是不使用模拟。这往往会发现一些在单元测试中漏掉的问题。这些测试往往难以阅读，因为它们通常在规范框架的before_each和after_each部分中涉及很多或工作，因为系统必须经常达到某种状态才能使测试有意义。
功能测试 我们通常以结构化但手动的方式进行。我们玩过 Selenium 和 Windmill，它们很酷，但至少对我们来说还没有。
我想听听其他人是如何做事的。你认为如果集成测试或功能测试做得足够好，另一个可以忽略吗？
我们已经体验到，一套可靠的硒测试实际上很好地总结了客户对质量的期望。所以，本质上我们一直在讨论：如果编写 selenium 测试和编写单元测试一样简单，我们应该少关注单元测试。
如果某个地方存在一个对应用程序没有任何影响的错误，那么谁真正在乎呢？但总是存在围绕现实生活复杂性的问题。你确定你的功能测试捕捉到了正确的场景吗？其他系统可能会导致在应用程序的行为中不直接可见的潜在复杂性。
实际上，一旦您深入研究了最初的问题，编写 selenium 测试（使用适当的编程语言，而不是 selenese）确实变得非常简单和有趣。但是我们还不愿意放弃我们的单元测试......
单元测试、集成测试和功能测试都有不同的用途。您不应该仅仅因为其他的以高可靠性运行而丢弃一个。
我会说（这只是一个意见问题）你的功能测试是你真正的测试。即那些实际模拟应用程序实际使用的测试。因此，无论如何，永远不要摆脱它们。
听起来你有一个体面的系统。如果您没有什么可失去的，请保留它。
在我目前的客户中，我们并没有真正区分单元测试和集成测试。业务实体如此依赖底层数据层（使用本土 ORM 框架），实际上我们几乎没有或根本没有真正的单元测试。
构建服务器在 Team Build 中使用持续集成 (CI) 进行设置，为了防止这种情况因缓慢的测试而陷入困境（完整的测试套件需要一个多小时才能在服务器上运行），我们将测试分为“缓慢”每天运行两次的测试和作为持续集成的一部分运行的“快速”测试。通过在测试方法上设置一个属性，构建服务器可以区分两者之间的区别。
一般来说，“慢”测试是任何需要进行数据访问、使用网络服务或类似的测试。按照惯例，这些将被视为集成测试或功能测试。示例包括：CRUD 测试、需要一组对象才能使用的业务验证规则测试等。
“快速”测试更像是单元测试，您可以在其中合理地隔离单个对象的状态和行为以进行测试。
我认为任何在十分之一秒或更短时间内运行的测试都是“快速”的。其他任何东西都很慢，可能不应该作为 CI 的一部分运行。
我同意您不应该过于拘泥于您在开发过程中使用的测试的“风味”（当然，将验收标准表示为测试是例外）。个人开发人员应该根据自己的判断来决定哪种类型的测试最适合他们的代码。坚持对业务实体进行单元测试可能不会揭示 CRUD 测试会出现的错误等等......
我将单元测试比作确保段落中的单词拼写正确。功能测试就像确保段落有意义，并且在它所在的文档中很好地流动。
我倾向于不区分 TDD 中的各种测试风格。对我来说，TDD 是测试驱动开发，而不是单元测试驱动开发。所以我的 TDD 实践结合了单元测试、集成测试、功能测试和验收测试。这导致某些组件被某些类型的测试覆盖，而其他组件以非常实用的方式被其他类型的测试覆盖。
我问了一个关于这种做法的相关性的问题，简短的回答是，在实践中，快速/简单的测试在每次构建时自动运行，而慢速/复杂的测试运行频率较低。
我的公司进行功能测试，但不进行单元或集成测试。我试图鼓励我们采用它们，我认为它们鼓励更好的设计和更快的迹象表明一切都很好。如果您进行功能测试，您是否需要单元测试？
我真的很喜欢 Gojko Adzic 的“面子测试”概念，以此来确定您通过 UI 测试的内容：http: //gojko.net/2007/09/25/effective-user-interface-testing/
你应该做所有这些，因为单元、集成和功能测试都有不同的用途。
属于我很重要的一点是，编写测试的方式很重要，TDD 是不够的，BDD（行为驱动开发）给出了一个很好的方法......