Debug.Assert vs代码契约使用

Question

什么时候我应该在代码契约上使用debug.assert，反之亦然？我想检查一个方法的前提条件，但我在选择其中一个方法时感到困惑。我有一些单元测试，我想在其中测试失败的场景和期望的异常。

在同一个方法上使用Debug.Assert和代码契约是一种好的做法吗？如果是这样，那么编写代码的顺序是什么？

Debug.Assert(parameter!= null);
Contract.Requires<ArgumentNullException>(parameter != null, "parameter");

或

Contract.Requires<ArgumentNullException>(parameter != null, "parameter");
Debug.Assert(parameter!= null);

这背后有没有道理呢？

Answer 1

这是两件不同的事情。调试断言仅在代码编译为debug时执行，因此将仅在debug下检查/断言。这个想法是用来对你正在开发的代码进行“健全检查”。代码契约可以在调试或发布中使用。他们保证方法的前置条件和后置条件符合方法的期望(满足合同)。还有一个提供类似功能的测试框架，用于检查测试符合性。

在开发代码时(以及在以后的维护开发中)，请在需要时使用Debug.Assert，以确保某些内容符合预期。

当您希望确保调试和发布中的条件都为真时，请使用代码协定。契约还允许某些形式的静态分析，这有助于验证您的程序是“正确的”。

在创建单元测试时使用测试框架断言。

Answer 2

就我个人而言，我不会同时使用Debug.Assert和代码契约来强制新编写的代码中的前提条件-- IMO代码契约取代了Debug.Assert，因为它们提供了一套更全面的检查，更不用说可以在代码进入运行时之前执行的静态检查所带来的好处。在Debug.Assert和Contracts中维护重复的前置条件检查将很麻烦。

基本原理：

• 你不需要重新编码任何你可能已经在Debug.Assert或throw代码中编码的遗留前提条件-你可以保留现有的前提检查代码，并且如果你构建时契约运行时检查设置为None，那么System.Diagnostics.Debug在没有/d:DEBUG的情况下构建时可以获得相同的未检查的“发布模式”行为。Ref 6.2.1 in the Docs
• Contracts允许开发人员在代码中更具表现力地说明检测到无效状态的原因-例如，是否直接因为带外参数(Contract.Requires)而导致无效状态。否则，Contract.Assert或Contract.Assume可以检查一般状态，并且可以使用Contract.Ensures来表示离开方法时状态的“保证正确性”。
• 和最棒的是，静态检查可以在你构建代码时强制执行这些约定-这样你就有机会通过设计时或编译时警告来发现错误，而不是等待运行时。可以将合同检查添加到持续集成中，以查找non-compliance.

一个警告:如果你要编写故意违反合同的单元测试，你可能需要处理ContractException - Jon Skeet很好地解释了这一点。例如，将测试设置中的Contract.ContractFailed handler连接到调用SetHandled的处理程序，然后抛出一个公共异常，您可以在UT中捕获并断言该异常。