复杂应用的业务逻辑自动化测试有着悠久的历史，从最早的验证器测试脚本到现代微服务测试。随着架构的复杂化（单体、SOA、微服务和宏服务），出现了一个问题：一个层次的架构变更往往会破坏其他层次的测试。
问题在于需要编写对应用层之间交互重组（如合同、数据结构、业务过程的改变）稳健的测试。测试常常依赖于实现细节，导致它们变得“脆弱”和难以维护。
解决方案是按照“黑箱”的原则构建测试，关注输入/输出数据，使用抽象层来访问系统实体（例如，在架构中使用服务层和领域层）。必须将业务逻辑与基础设施细节分离，并使用mocks/stubs来处理外部依赖，以确保测试的隔离性和稳定性。
关键特点：
通过UI层检查业务逻辑与通过API/领域层的检查有什么区别？
UI测试通常对变化的抵抗力较弱，因为界面的细微变化会导致测试失败。通过API或领域层的测试对前端的依赖较少，更成功地隔离了业务规则的验证。
是否需要对所有业务逻辑的依赖进行mock以进行测试？
不！不应对可以在测试环境中实现的部分进行mock（例如，用轻量级内存替代数据库）。mock对于复杂的、昂贵的或外部的依赖是必要的。完全mock可能会导致“虚假”测试，无法反映实际场景。
仅对业务逻辑进行积极场景测试是否足够？
不！重要的是覆盖所有边缘情况和消极场景，否则关键错误可能会被忽视，这将导致主要业务过程的脆弱性。
在项目中，只有通过UI Selenium测试、直接与按钮和表单交互来测试业务逻辑。每次前端重构都会导致自动测试的大面积失败。
优点：
缺点：
在项目中实现了API和单元测试的中间层。UI只覆盖关键路径，所有其他验证都通过服务层进行，并对昂贵的服务进行了mock。
优点：
缺点：