我注意到人们有时会避免进行彻底的测试。 对于某些人来说，这听起来像是伪造的，但请听我说……

测试会产生被困的感觉，每引入一个新的测试，负担就会加重。 建立稳定，无干扰且质量保证的测试套件是一项艰巨的任务……但是这些问题为什么会浮出水面？

大多数人可以同意，对任何类型的产品以一种或另一种方式进行的测试是揭示质量并随后提高质量的好方法。 但是，当您指定一组静态测试，然后在产品的整个生命周期（即回归测试）中连续重新执行它时，测试过程可能会出现问题。

停下来思考一下……接口和抽象为客户提供什么价值？ 他们提供了一种享受“特别”有价值的服务的方式，而不必担心向我们提供“如何”的复杂内部细节。

接口不是软件开发所独有的，它们在我们日常社区中无处不在。 考虑让丰田维修。 雇主迈克非常擅长使用定制工具修理丰田汽车。 但是，作为客户，您是否真的在乎*如何*并且*由谁*修理过汽车，如果您可以看到故障部件已被更换并且汽车的工作状况比以前更好？

迈克将更好地完成自己的工作，而不会被无法跟上他的尖端技术的人们所困扰。 迈克可能会放弃或学习更好的方法，从而丢弃一些旧的定制工具。 最好确保公司服务整体上可以为​​各种问题和客户提供高质量的服务。

这是一个简化，但是您明白了。

我观察到，测试工作（过于频繁）试图在未真正考虑后果的情况下验证未指定的实现细节。 过多的指定不正确的测试很容易导致混乱的维护噩梦 ，使未来的产品开发变得困难且无济于事。 一旦出现这些症状，开发人员便会停止不断进行改进 ，以避免重构过程中出现问题以及与QA发生传染性冲突，从而对产品质量造成的伤害大于对产品质量的帮助。

内部领域专家可以帮助您了解基本的业务战略以及真正使公司成功的关键 。 在指定内部和外部业务流程都可见的重要接口时，请三思而后行。 摘录的抽象内容捕获了高级目标和概念，而不是复杂的实现细节。 将您的设计和测试工作集中在这些接口上，您将获得稳定性。

请记住，企业竞争异常激烈且充满活力，因此Swift变化以超越竞争对手。 在体系结构中定义接口和测试时，为业务发展和发展提供灵活性。 使接口可以组合成独特的服务组合，以支持不可预见的业务功能 ，以最小的努力实现价值的最大化。

未来将永远是未知的，所以不要对明天会带来太多的假设。

没有水晶球之类的东西。

参考： 水晶球幻想我们JCG伙伴的Kristoffer干燥的deephacks博客。