我正在使用断点进行调试，并且意识到断言调用了吗？我认为这仅用于单元测试。除了断点，它还有什么作用？既然可以断点，为什么要使用Assert？

解决方案

在调试编译中，" Assert"将布尔条件作为参数，如果条件为假，则显示错误对话框。如果条件为真，程序将继续运行而不会中断。

如果我们在Release中编译，则所有Debug.Assert都会被自动排除。

断言允许我们断言在代码中适用的条件(发布前或者发布前)。这是一种记录意图并让调试器通过对话框通知方法，如果意图没有得到满足。

与断点不同，断言与代码一起使用，可用于添加有关意图的其他详细信息。

断言可以在测试和发布之间给出单独的消息传递行为。例如，

Debug.Assert(x> 2)

仅在运行"调试"版本而不是发行版本的情况下才会触发中断。
这里有此行为的完整示例

我们应该在不需要断行每一行代码来检查变量的情况下使用它，但是如果确实存在某些情况，我们确实希望获得某种反馈，例如：

Debug.Assert(someObject != null, "someObject is null! this could totally be a bug!");

Assert还为我们提供了另一个嘲笑Microsoft UI设计技能的机会。我的意思是：一个带有三个按钮的对话框，分别是"中止"，"重试"，"忽略"，并在标题栏中说明了如何解释它们！

从代码完成

8 Defensive Programming
  
  8.2 Assertions
  
  An assertion is code that’s used during development—usually a routine
  or macro—that allows a program to check itself as it runs. When an
  assertion is true, that means everything is operating as expected.
  When it’s false, that means it has detected an unexpected error in the
  code. For example, if the system assumes that a customer-information
  file will never have more than 50,000 records, the program might
  contain an assertion that the number of records is lessthan or equal
  to 50,000. As long as the number of records is less than or equal to
  50,000, the assertion will be silent. If it encounters more than
  50,000 records, however, it will loudly “assert” that there is an
  error in the program.  
  
  Assertions are especially useful in large, complicated programs and
  in high reliability programs. They enable programmers to more quickly
  flush out mismatched interface assumptions, errors that creep in when
  code is modified, and so on. 
  
  An assertion usually takes two arguments: a boolean expression that
  describes the assumption that’s supposed to be true and a message to
  display if it isn’t. 
  
  (…) 
  
  Normally, you don’t want users to see assertion messages in
  production code; assertions are primarily for use during development
  and maintenance. Assertions are normally compiled into the code at
  development time and compiled out of the code for production. During
  development, assertions flush out contradictory assumptions,
  unexpected conditions, bad values passed to routines, and so on.
  During production, they are compiled out of the code so that the
  assertions don’t degrade system performance.

我认为的方法是Debug.Assert，它是一种建立关于应如何调用方法的协定的方法，重点是关于参数值(而不是类型)的细节。例如，如果不应该在第二个参数中发送null，则在该参数周围添加Assert，以告知使用者不要这样做。

它可以防止他人以笨拙的方式使用代码。但是，它也允许这种笨拙的方式进入生产过程，并且不会向客户发出令人讨厌的消息(假设我们构建的是Release版本)。

断言在按合同设计(DbC)中占有重要地位，据我所知，它是由Bertand的Meyer提出/认可的。 1997. 面向对象的软件构造。

一个重要的功能是它们一定不能产生副作用，例如，我们可以使用if语句(防御性编程)来处理异常或者采取其他措施。

断言用于检查合同的前/后条件，客户/客户与供应商的关系，客户必须确保满足供应商的前条件，例如。发送5，供应商必须确保满足后置条件，例如。提供12朵玫瑰。
(对客户/供应商的简单解释可以接受更少，但交付更多，但是可以声明)。
C还引入了Trace.Assert()，可用于发布代码。

要回答这个问题，它们仍然有用，但是会增加代码的复杂度和可读性，并增加维护时间和难度。
我们还应该使用它们吗？是的，
我们都会使用它们吗？可能不是，或者没有达到Meyer描述的程度。

(即使我学习过此技术的OU Java课程也仅显示了简单的示例，而该代码中的其余代码并未对大多数代码强制执行DbC断言规则，但被假定为可确保程序正确性！)