《架构整洁之道》第 28 章 测试边界

测试代码也是系统的一部分，测试代码的地位比其他组件更独特。

测试也是一种系统组件

关于测试，总会有许多讨论，测试是系统一部分还是独立于系统之外？测试分为几种？单元测试和集成测试有什么不一样？质量检查测试，功能性测试，Cucumber 测试，TDD 测试，BDD 测试，分别又是什么？

还好我们没必要去讨论这些，因为在架构角度来看，所有测试都是一样的。

究其本质而言，测试组件也要遵守依赖关系原则，它始终都是依赖于被测试部分代码的，并且不会有其他组件会去依赖测试组件。另外测试组件也应当是可以被独立部署的，它是系统中最独立的一个组件，因为系统的正常运行，并不会需要使用到测试组件，它只是为了支持开发过程而存在的。

但是测试组件仍然是系统架构中不可缺少的组件，它在许多方面都反映了系统中其他组件所应遵循的设计模型。

可测试性设计

由于测试组件的独立性，以及往往不会部署到正式环境，开发者通常忽略测试的重要性，这是极为错误的。测试如果没有被集成到系统设计中，往往是非常脆弱的，这种脆弱性会使得系统变得死板，非常难以更改。

这里的关键就是耦合，如果测试代码和系统强耦合，哪怕系统一点点变更那也会导致相关测试要变更。这个问题是很严重的，修改一个通用的系统组件，可以能导致成千上百个测试出现问题。我们将这种问题称为脆弱的测试问题。

脆弱的测试，还会导致系统死板，因为程序员知道一旦修改逻辑，就可能导致很多测试出错，就会抵制修改。

想要解决这个问题，就必须考虑到系统的可测试性。软件开发第一要以，不要依赖于可变或经常变动的东西。比如，GUI往往是多变的，所以通过GUI来验证系统，那必然是脆弱的，我们应当让业务系统不需要通过GUI也能被测试。

测试专用 API

设计一个可测试的系统，方法之一就是创建一套专门供测试使用的API，它应该被赋予超级权限，绕过数据库操作，强制将系统设置为某种可测试的状态中。这种测试API就是为了解耦，和应用程序的代码结构分开。

结构性耦合

结构性耦合是测试代码中耦合关系最强大，最阴险的。假设有一组类需要测试，每个类中有一个测试函数，这就是结构性耦合。如果类和函数发生了变更，就极容易导致测试的变更。

测试专用API就是为了保证，应用程序的变更，不会导致测试代码的变更，测试代码的变更，也不会影响到应用程序的变更。

安全性

这种具有超级权限的测试专用API，是非常危险的，所以我们应当将它放置在一个独立的，可单独部署的组件中。

本章小结

测试不是独立于整个系统之外的，它是系统的一个重要的组成部分，我们要精心设计它，才能让它发挥验证系统稳定性的作用。如果不按系统组成部分来设计它，往往就会变得脆弱难以维护。