Questions tagged «assertions»

断言测试和单元测试都充当代码库的文档，并且是发现错误的一种手段。主要区别在于，断言充当健全性检查并查看实际输入，而单元测试则在特定的模拟输入上运行，并且是针对单个明确定义的“正确答案”的测试。使用断言与单元测试作为验证正确性的主要方法有哪些相对优点？您认为应该重点强调哪个？

51 testing  unit-testing  assertions 

通常，当我编写一个函数时，我想确保其输入有效，以便尽早检测到此类错误（我相信这些被称为前提条件）。当前提条件失败时，我总是抛出异常。但是我开始怀疑这是否是最佳做法，如果不是，则断言是否更合适。 所以我应该什么时候做：什么时候使用断言，什么时候抛出异常？

38 exceptions  assertions 

我非常喜欢assert用C ++代码编写检查，以此来捕获开发过程中由于程序中的逻辑错误而无法发生但确实会发生的情况。通常，这是一个好习惯。 但是，我注意到，我编写的某些函数（属于复杂类的一部分）具有5个以上的断言，就可读性和可维护性而言，这似乎可能是一种不良的编程习惯。我认为它仍然很棒，因为每个人都需要我考虑函数的前置条件和后置条件，它们确实有助于捕获错误。但是，我只是想把它放在那儿，以问在需要进行大量检查的情况下，是否存在更好的范例来捕获逻辑错误。 Emacs注释：由于Emacs是我的首选IDE，因此我将它的assert语句略显灰色，这有助于减少它们可以提供的混乱感。这是我添加到.emacs文件中的内容： ; gray out the "assert(...)" wrapper (add-hook 'c-mode-common-hook (lambda () (font-lock-add-keywords nil '(("\\<\\(assert\(.*\);\\)" 1 '(:foreground "#444444") t))))) ; gray out the stuff inside parenthesis with a slightly lighter color (add-hook 'c-mode-common-hook (lambda () (font-lock-add-keywords nil '(("\\<assert\\(\(.*\);\\)" 1 '(:foreground "#666666") t)))))

33 c++  debugging  error-handling  assertions 

我最近遇到了一些新编写的代码，这些代码中散布着许多Debug.Assert（C＃）。 尽管总体上使用了TDD，BDD和单元测试，我们是否仍应广泛使用它？

23 unit-testing  assertions 

assertC ++中的默认行为是在发行版本中不执行任何操作。我认为这样做是出于性能原因，也许是为了防止用户看到讨厌的错误消息。 但是，我认为，那些assert将被触发但被禁用的情况更加麻烦，因为应用程序可能因为某些不变式被破坏而以更糟糕的方式崩溃。 另外，对我而言，性能参数仅在可衡量的问题时才有效。assert我代码中的大多数不会比复杂得多 assert(ptr != nullptr); 这将对大多数代码产生很小的影响。 这使我想到一个问题：断言（意味着概念，而不是特定的实现）是否应该在发布版本中有效？为什么不）？ 请注意，此问题不是关于如何在发布版本中启用断言（例如#undef _NDEBUG或使用自定义断言实现）。此外，这不是在第三方/标准库代码中启用断言，而是在我控制的代码中启用断言。

20 c++  release  assertions 

我真的爱上了单元测试和TDD-我被测试感染了。 但是，单元测试通常用于公共方法。有时候，尽管我确实也必须在私有方法中测试一些假设-断言，因为其中一些是“危险的”，并且重构无济于事。（我知道，测试框架允许测试私有方法）。 因此，我的习惯是私有方法的第一行和最后一行都是断言。 但是，我注意到我倾向于“肯定”地在公共方法（以及私有方法）中使用断言。因为公共方法假设是由单元测试框架从外部进行测试的，所以这可能是“测试重复”吗？ 有人会认为太多的断言是代码的味道吗？

19 testing  code-quality  tdd  code-smell  assertions 

可以添加这样的延迟断言吗 var actualKittens = actualKittens.Select(kitten => { Assert.IsСute(kitten); return kitten }); 为什么？因此，即使使用期望实现实例化的语句，我也可以仅迭代一次： CollectionAssert.AreEquivalent(expectedKittens, actualKittens.ToList()); 而且它可能不仅是Select，而且是定义了迭代器且具有大量检查和逻辑（例如，一些计数和过滤）的方法。 令人怀疑的种子是在测试失败的情况下读取和调试此类代码的复杂性。

18 c#  unit-testing  linq  iterator  assertions 

最近，我一直在努力了解什么是正确的检查量以及什么是正确的方法。 我对此有一些疑问： 检查错误（错误的输入，错误的状态等）的正确方法是什么？显式检查错误，还是使用可以从最终代码中优化的断言之类的函数，更好？我感觉像是用很多额外的代码来明确地检查程序是否杂乱，无论如何在大多数情况下都不应该执行这些代码，更不用说大多数错误都以中止/退出失败而告终。为什么将具有显式检查的功能弄乱只是为了中止？我一直在寻找断言而不是显式检查错误，却很少能真正解释什么时候做。 大多数人说“使用断言检查逻辑错误，并使用显式检查检查其他故障”。但这似乎并没有使我们走的太远。我们可以说这是可行的： Malloc returning null, check explictly API user inserting odd input for functions, use asserts 这会使我在错误检查方面变得更好吗？我还可以做些什么？我真的很想改进和编写更好的“专业”代码。

13 c  testing  assertions 

我正在编写一个对文本文件执行某些操作的脚本（尽管这样做与我的问题无关）。因此，在对文件执行某些操作之前，我想检查文件是否存在。我可以做到，没问题，但是问题更多是美学问题。 这是我的代码，以两种不同的方式实现同​​一件事。 def modify_file(filename): assert os.path.isfile(filename), 'file does NOT exist.' Traceback (most recent call last): File "clean_files.py", line 15, in <module> print(clean_file('tes3t.txt')) File "clean_files.py", line 8, in clean_file assert os.path.isfile(filename), 'file does NOT exist.' AssertionError: file does NOT exist. 要么： def modify_file(filename): if not os.path.isfile(filename): return 'file does NOT exist.' …

12 python  error-handling  error-messages  assertions 

关于鸭子打字： 通过惯用性地不测试方法和函数体中的自变量类型，依靠文档，清晰的代码和测试来确保正确使用，可以帮助进行鸭子键入。 关于论证验证（EAFP：比宽恕更容易获得宽恕）。来自这里的改编示例： ...被认为是更pythonic的： def my_method(self, key): try: value = self.a_dict[member] except TypeError: # do something else 这意味着使用您的代码的其他任何人都不必使用真正的字典或子类-他们可以使用实现映射接口的任何对象。 不幸的是，实际上并不是那么简单。如果上述示例中的member可能是整数怎么办？整数是不可变的-因此将它们用作字典键是完全合理的。但是，它们也用于索引序列类型对象。如果member恰好是整数，则示例二可以让列表，字符串以及字典通过。 关于断言编程： 断言是检查程序内部状态是否符合程序员期望的一种系统方法，目的是捕获错误。特别是，它们非常适合捕获编写代码时做出的错误假设，或捕获其他程序员滥用接口的情况。此外，通过使程序员的假设显而易见，它们可以在一定程度上充当内联文档。（“显式优于隐式。”） 提到的概念有时会发生冲突，因此在选择是否完全不进行任何数据验证，进行强力验证或使用断言时，我会依靠以下因素： 强力验证。通过强力验证，我的意思是引发自定义Exception（ApiError例如）。如果我的函数/方法是公共API的一部分，则最好验证参数以显示有关意外类型的良好错误消息。通过检查类型，我并不是指仅使用isinstance，而是通过的对象是否支持所需的接口（鸭子输入）。当我记录API并指定期望的类型并且用户可能想以意外方式使用我的函数时，在检查这些假设时，我会感到更加安全。我通常使用isinstance，如果以后要支持其他类型或鸭子，则可以更改验证逻辑。 断言编程。如果我的代码是新的，我会使用很多断言。您对此有何建议？以后是否从代码中删除断言？ 如果我的函数/方法不是API的一部分，而是将其某些参数传递给我未编写，研究或测试的其他代码，则我会根据被调用的接口执行很多断言。我的逻辑背后-最好在我的代码中失败，然后在堆栈跟踪中加深10个级别，出现难以理解的错误，这迫使进行大量调试，然后无论如何都将断言添加到我的代码中。 断言，关于何时使用或不使用类型/值验证的评论和建议？很抱歉，问题不是最好的表述。 例如，考虑以下函数，其中Customer是SQLAlchemy声明性模型： def add_customer(self, customer): """Save new customer into the database. @param customer: Customer instance, whose id is None @return: merged into global session customer …

10 python  validation  assertions  duck-typing 

我非常喜欢用我使用的语言编写断言，合同或任何类型的支票。让我感到困扰的一件事是，我不确定处理重复支票的通用做法。 情况示例：我首先编写以下函数 void DoSomething( object obj ) { Contract.Requires<ArgumentNullException>( obj != null ); //code using obj } 然后几个小时后，我编写了另一个函数，该函数调用第一个函数。由于所有内容仍在内存中，因此我决定不重复合同，因为我知道DoSomething已经检查了一个空对象： void DoSomethingElse( object obj ) { //no Requires here: DoSomething will do that already DoSomething( obj ); //code using obj } 明显的问题：DoSomethingElse现在依赖于DoSomething验证obj不为null。因此，应该DoSomething决定不再检查，或者如果我决定使用另一个函数，则可能不再检查obj。毕竟，这导致我要编写此实现： void DoSomethingElse( object obj ) { Contract.Requires<ArgumentNullException>( obj != null …

10 assertions  code-contracts