生产代码中的NUnit断言

我正在尝试在生产代码中找到断言的最佳做法，但我很惊讶我找到的信息很少。生产代码中的NUnit断言

首先是否可以在生产代码中声明断言？

其次，我发现内置的Debug.Assert for .NET本质上会自动禁用生产代码，并且实际上只能在开发环境中运行。这是真的吗，NUnit是否也有内置的这个功能？

例如，如果我在生产代码中具有以下内容，断言将被忽略？

var sortedActuals = actuals.OrderByDescending(a => 
        { 
         Assert.That(a.GLPeriodDateTime, Is.Not.Null, "GLPeriodDateTime was null when it should not be"); 
         return a.GLPeriodDateTime.Value; 
        })

来源

2017-10-20 Nathan Kamenar

你试过了吗？结果是什么？ – mason

我不会在生产代码中使用NUnit声明。如果你想检查你可以提出自己的例外或使用代码合同。在这种情况下，它看起来像'a'的类应该确保'GLPeriodDateTime'永远不为空。 – Lee

您不应该在生产代码中使用NUnit声明。如果断言失败，则NUnit断言总是会引发异常。 NUnit不检查它是否在Debug或Release（Production）中运行。 NUnit断言也被设计为在NUnit测试中使用。

对于您的实际代码中的断言，您应该使用Debug.Assert。它的功能较少，但是它在编译模式下编译出来，所以不会使您的应用程序在生产环境中崩溃。

来源

2017-10-20 14:09:45

我将从第二个问题开始。不，这个说法不会被忽略。在C＃项目的构建配置中，您可以指定构建忽略DEBUG常量。这就是Debug.Assert语句被删除的方式（Visual Studio为您提供默认设置的构建配置）。

至于你的第一个问题，我会说在生产代码中有NUnit断言是不可接受的。问问自己，使用断言对于异常或其他错误状态有什么好处？

如果GLPeriodDateTime在用户没有错误的情况下可以为空，则可能需要在发布之前进行更彻底的测试以解决此问题。如果用户存在错误，则有更好的方法（例如异常）通知用户错误。断言适用于开发人员使用。

来源

2017-10-20 14:01:37 ScoobyDrew18

感谢您的输入。我不认为它永远是空的，因为它从用户输入需要的字段。我仍然希望为开发人员进行检查，不过因为有些数据是从旧系统导入的，而“应该”总是有这些数据，所以不检查它是不明智的。我想我会使用内置的断言让开发人员知道但不会打扰用户。 –

NUnit断言必须在发布版本中起作用，因为发布版本必须经过测试。出于多种原因，您不应在生产代码中包含NUnit声明。

NUnit的断言（以及Debug.Assert的）旨在检测您代码的问题。提供给您的应用程序的错误数据是正常应用程序流程的一部分，应该由您的生产代码进行检测和处理。
断言旨在NUnit的控制下运行，它知道结果的含义。例如，某些断言在失败时会抛出异常，而其他断言则不会。您需要知道差异才能对其进行有效使用。
还有其他的，行之有效的处置不良数据，包括异常处理，自定义错误消息等方式
最有可能的，你要使用NUnit的约束语法从NUnit的测试分离。这是一个很好的语法，有几个人要求我们把它作为一个单独的软件包拆分出来。如果我们这样做了，你可以使用它，但不幸的是我们还没有。

来源

2017-10-20 15:40:16 Charlie

另一个很好的答案，谢谢。 –

生产代码中的NUnit断言

回答

相关问题