我用的断点调试,我意识到断言电话吗? 我认为这是唯一的单元测试。 这是什么做的比断点多? 因为我可以断点,我为什么要使用断言?
Answer 1:
在调试编译, Assert
发生在一个布尔条件作为参数,并显示错误对话框如果条件是假的。 如果条件为真程序进行,没有任何中断。
如果您在Release编译,所有Debug.Assert
的自动排除在外。
Answer 2:
从代码完成
8防御性编程
8.2断言
断言是发展的,通常是一个例程或宏,它允许一个程序来检查本身,因为它运行时使用的代码。 当一个断言是真的,这意味着预期一切操作。 当它是假的,这意味着它已检测到代码中的意外错误。 例如,如果系统假定客户信息文件将永远不会有超过50,000条记录,该程序可能包含断言的记录数小于或等于50,000。 只要记录的数量小于或等于50000,断言将是沉默。 如果遇到超过50,000条记录,但是,它会大声地“断言”不存在程序中的错误。
断言是在大型,复杂的程序和高可靠性的方案特别有用。 他们使程序员能够更迅速地冲洗掉不匹配的接口假设,当代码被修改,等等蠕变错误。
断言通常需要两个参数:一个描述应该是真实的假设,并显示如果不是消息的布尔表达式。
(......)
通常情况下,你不希望用户看到产品代码断言消息; 断言主要用于开发和维护过程中使用。 断言通常编译成在开发时的代码和编译了生产代码。 在开发过程中,断言冲洗矛盾的假设,意外情况,传递给程序错误值,依此类推。 在生产过程中,他们编出来的代码,这样的说法不降低系统性能。
Answer 3:
你应该使用它的时候,你不希望有断点的代码检查变量每个小行,但你想获得某种形式的反馈,如果某些情况下都存在,例如:
Debug.Assert(someObject != null, "someObject is null! this could totally be a bug!");
Answer 4:
断言还为您提供了另一个机会,在微软的UI设计技巧窃喜。 我的意思是:有三个按钮的对话中止,重试,忽略,以及如何解释他们在标题栏中的解释!
Answer 5:
断言允许你断言条件(后或前)适用于你的代码。 这是记录你的意图,并具有调试器告诉你一个对话框,如果你的目的是不能满足的一种方式。
不像一个断点,断言去与你的代码,并可以用来添加关于你的意图更多细节。
Answer 6:
断言可以帮助你给测试和发布之间的独立的信息的行为。 例如,
Debug.Assert(x > 2)
如果您运行的是“调试”的构建,而不是一个发布版本只会触发中断。 有此行为的完整的例子在这里
Answer 7:
首先, Assert()
方法可用于Trace
和Debug
类。
Debug.Assert()
仅在调试模式下执行。
Trace.Assert()
在调试和发布模式下执行。
下面是一个例子:
int i = 1 + 3;
// Debug.Assert method in Debug mode fails, since i == 4
Debug.Assert(i == 3);
Debug.WriteLine(i == 3, "i is equal to 3");
// Trace.Assert method in Release mode is not failing.
Trace.Assert(i == 4);
Trace.WriteLine(i == 4, "i is equla to 4");
Console.WriteLine("Press a key to continue...");
Console.ReadLine();
在发行模式调试模式运行该代码,然后。
你会发现,调试模式你的代码中Debug.Assert
语句失败,你会得到显示应用程序的当前堆栈跟踪的消息框。 这不是在释放模式发生以来Trace.Assert()
条件为真(i == 4)
WriteLine()
方法简单地让你登录的信息到Visual Studio输出的选项。
Answer 8:
我认为它的方式是Debug.Assert的是要建立一个约的方法应该是怎样被称为合同的方式,集中展示一个放慢参数(而不仅仅是类型)的值细节。 例如,如果你不应该在第二个参数发送一个空添加的断言围绕参数告诉消费者不要那样做。
它可以防止有人利用在愚蠢的方式你的代码。 但它也允许愚蠢的途中要经过生产,而不是给讨厌的消息给客户(假设你建立一个发布版本)。
Answer 9:
断言巨资配备的契约式设计(DBC),它作为我的理解是引种/迈尔,Bertand认可。 1997年面向对象的软件敷设渠道。
一个重要的特点是,它们不能产生副作用,例如,你可以处理异常或采取不同的疗程与if语句(防御性编程)。
断言是用于检查合同的前/后条件下,客户/供应商关系 - 客户必须确保供应商的先决条件得到满足如。 发送£5和供应商必须确保事后条件得到满足如。 提供12种玫瑰。 (客户/供应商的只是简单的解释 - 可以接受更低,并提供更多,而是断言)。 C#还引入Trace.Assert(),它可用于释放代码。
要回答这个问题,是的,他们仍然是有用的,但会增加复杂性+可读性代码和时间+难以维持。 如果我们仍然使用他们? 是的,我们都将使用它们? 或许不会,或不迈耶这样描述的程度。
(即使是OU的Java课程,我知道了这种技术只显示简单的例子和有代码没有强制执行的大部分代码在DBC断言其余规则,但被认为可以用来保证程序的正确性!)