如果我一直努力创建单元测试，然后在将我的应用程序放在一起时进行集成测试，那么当我想要重构架构时，我的手是不是有点束手无策？
似乎即使只是将一个方法从一个类拉到另一个类也可能需要相当多的开销才能使测试再次运行。
最佳答案
也许
如果您的单元测试是 "change detector" ，镜像您的代码的实现，那么重构的开销可能不小。
此外，由于单元测试通常只处理实现细节，因此它们会随着体系结构的变化而失败。理想情况下，这种失败将是建设性的反馈，并将告知您代码的其他部分期望什么样的契约(Contract)。
编写测试非常简单，编写有意义的测试，不提供误报，孤立的，没有级联故障的方法要困难得多:)(仍在尝试在这里弄清楚)。
沿库的公共(public)接口(interface)进行测试应该有助于最大程度地减少实现失败。此外，进行大量单独的单元测试应该有助于最大程度地减少组件间测试失败。
我发现一种非常有用的策略是在开发 MVP 或原型(prototype)时，在探索实现的过程中，在验收级别或功能级别进行测试有助于验证产品，同时允许在实现过程中放宽要求。这些测试通常沿服务公共(public)接口(interface)发生，而不是沿代码发生。
关于unit-testing - 大量的单元和集成测试是否会使架构更改变得困难？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40710879/