我已阅读了所有这些方法：合同设计，面向方面编程，测试驱动开发和单元测试。在实践中，我只使用单元测试和AOP（AspectJ）。我知道这是不同的事情，但似乎我对他们的目的有一些妄想。DBC，AOP，TDD和单元测试目标之间的差异
问题\索取：您可以为DBC，AOP，TDD的目的和单元测试之间的差异一个简短的调查？你能回顾一下我的结论并指出我错在哪里吗？
我的结论：
IMMO DBC，TDD和AOP没有直接的可比性，是具有非常不同的目的完全不同的事情，我试图解释一下这个技术是我个人的看法：
DBC目的其定义语义（以前置条件，后置条件和不变量的形式）以确保一段代码的正确性。根据DBC的实现，这些合约可以在运行时断言，或者可以在编译时尝试执行。老实说，我不得不说，我从来没有使用过，我从来没有看到一个真正的DBC系统构建，没有DBC的良好工具支持，并且在使用DBC方面很少有实际的建议。 TDD其关于通过使用示例（又称测试）来确保正确性，以及TDD其使用快速反馈周期红绿重构的设计技术。与DBC一样，它也是一种无缺陷构建软件的技术，但采用了一种非常不同的方法。我在很多项目中使用TDD超过六年（或多一点我不记得），对我而言，它现在是开发软件的“自然”方式，当然这是个人选择而非一般建议，自己尝试。
AOP它的另一个截然不同的东西，它是一种处理交叉担忧的方法，你可以用它来验证合同的强制执行情况吗？，可能是的，但是这不能超过其中一个无限用途AOP。只有我的观点，我不是AOP的忠实粉丝，我必须用很多AOP的东西来维护遗留的代码库，而IMMO AOP是一个非常复杂的方式来隐藏系统的重要功能。
我要在此一刺...
DBC - 这是一个编程方法，这种方法比较容易在与防御式编程对比了解。
设计按合同有关规定全面谁（客户端功能或功能提供商）是负责什么（合同）。功能提供商承诺：如果您符合我的先决条件（例如输入值为非负值），然后我保证我的后置条件（例如，然后我将返回值的平方根）。一个同样有效的合同是：如果你给我任何数字（没有先决条件），那么如果它是否定的，我会返回-1，否则我将返回数字的平方根。
使用这种方法，功能客户端显然负责检查在调用功能前满足前提条件。功能提供者可以自由地假定符合前提条件，但必须确保符合其后置条件。
将此与防御性编程进行对比，其中特征客户端和功能提供者将验证数据以防万一另一个不会。
DBC试图帮助开发人员通过降低其复杂性（更强的规格和更少的重复代码）来创建正确的代码。
如何实现DBC是排序的实现细节。您可以在没有任何工具支持的情况下完成DBC，只需在纸上定义API并实施它，以便客户检查（指定）前置条件并且提供商符合其后置条件（适用于所有有效的前提条件）。当然，工具支持帮助....
单元测试是一个简单的方式，以确保您的代码行为与您的预期（其中一数）。您可以对DBC代码或非DBC代码使用单元测试。单元测试和DBC在某种程度上是互补的，因为它很容易为定义良好的API规范编写单元测试;另一方面，如果您使用工具来支持DBC，则甚至可能会看到它们是重复的，因为合同可能最终会在单元测试和DBC工具中进行描述/验证。
TDD是另一种降低从不同角度开发代码的复杂性的方法。从功能规格开始，为其编写测试（它应该失败），编写使测试通过的生产代码（而不是更多）。 TDD代码仍然可以使用DBC（或不）。
AOP更像是一种技术 - 它是让代码运行到你想要的位置的一种替代方法。它可以用来支持很多事情，但我不会说“AOP是包含DBC的更广泛的概念”，不仅仅是我认为笔是一个比短篇小说更广泛的概念。
那么DBC优于单元测试的优点是什么？ –
对我而言，没有任何优势，DBC就像是一个永不履行的承诺，TDD是现在很多程序员都在实践中取得卓越成果的现实。 – AlfredoCasado