大型单元和集成测试套件是否会使架构更改变得困难？

Question

如果我一直在勤奋地创建单元测试，然后在我将应用程序组合在一起时进行集成测试，那么当我想重构架构时，我是不是有点束手无策？

似乎即使只是将一个方法从一个类拉到另一个类，也可能会有相当多的开销让测试再次工作。

Answer 1

也许吧

如果您的单元测试是镜像代码实现的"change detector"，那么重构可能会有大量的开销。

此外，由于单元测试通常只处理实现细节，因此随着体系结构的更改，单元测试将失败。理想情况下，此失败将是建设性的反馈，并将通知您代码的其他部分所期望的合同类型。

编写测试相当容易，编写有意义的测试，不提供假阳性，隔离的测试，以及没有级联失败的测试要困难得多:) (仍然试图在这里弄清楚)。

沿着库的公共接口进行测试应该有助于最小化实现失败。此外，拥有大量单独的单元测试，应该有助于最大限度地减少组件间测试失败。

我发现一种非常有用的策略是，当开发MVP或原型时，正在探索实现，在验收级别或功能级别的测试有助于验证产品，同时允许在实现中大量宽松。这些测试通常发生在服务公共接口上，而不是代码上。