我们正在使用完全测试驱动的方法构建应用程序。作为开发人员,我们非常熟悉单元测试,但还没有接触过集成/功能/验收测试。因此这篇文章。
该应用程序公开了一个 Web UI(HTML 资源),它调用一个安全的 REST API(使用 JSON 序列化),然后委托给一个独立于任何交付机制的核心域模型(事务性应用程序服务和业务实体)。REST API 最终将公开。持久性是使用关系数据库和 ORM 实现的。使用标准的 Java / Spring / Hibernate 技术栈。
如果我们想做纯 TDD,我们将编写以下测试:
- 用于 Web UI 的 Selenium / WebDriver 测试
- REST API 的集成测试
- 应用服务的集成测试
- 存储库的集成测试(持久性)
- Web 控制器的单元测试(REST API)
- 应用程序服务的单元测试
- 验证器的单元测试
我所说的集成测试是指针对部署在类似生产环境中的功能齐全的应用程序的测试。通过单元测试,我的意思是针对单个类的测试,其中协作者/依赖项已被测试替身(模拟、存根等)取代。
显然,每个测试都有不同的视角(Web 测试以用户为中心,API 测试以 API 消费者为中心,其他测试以开发人员为中心)并验证不同的断言(Web 测试的 HTML 元素内容、HTTP 响应和 API 测试的状态代码、应用程序测试的数据库内容和异常、单元测试的边缘案例等)。但是所有这些测试之间也有很多重叠,特别是在涉及到夹具时(例如,如果其他用户已经注册了相同的电子邮件,则用户无法注册)。因此,我们可以通过专注于较高层来避免编写其中一些测试(例如,只为重复电子邮件案例的用户注册编写 Web 测试),但如果较低层被重复使用,它们就会暴露出来。不同的客户端(例如批处理客户端使用的应用程序服务)。
所以我们最终想知道编写所有这些测试会有多大用处,以及我们如何才能更有效地使用我们的方法。你对此有什么看法?
我意识到这更像是一个讨论类型的问题,而不是一个有明确和可验证答案的问题,所以如果这不是合适的论坛,请您指导我到这些讨论的最佳论坛。
干杯!