生产代码中的 NUnit 断言答案

【问题标题】：NUnit assertions in production code生产代码中的 NUnit 断言
【发布时间】：2017-10-20 13:42:16
【问题描述】：

我正在尝试寻找在生产代码中使用断言的最佳实践，但我对我发现的信息如此之少感到惊讶。

首先，在生产代码中是否可以使用断言语句？

第二，我读到 .NET 的内置 Debug.Assert 本质上会自动为生产代码禁用自身，并且仅在开发环境中实际运行。这是真的吗？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;
                    })

【问题讨论】：

你试过了吗？结果如何？
我不会在生产代码中使用 NUnit 断言。如果您想检查，您可以提出自己的异常或使用代码合同。在这种情况下，a 的类看起来应该确保 GLPeriodDateTime 永远不会为空。

标签： c# asp.net testing nunit

【解决方案1】：

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

NUnit 断言（以及 Debug.Assert）旨在检测您的代码中的问题。提供给您的应用程序的不良数据是正常应用程序流程的一部分，应该由您的生产代码检测和处理。
断言旨在在 NUnit 的控制下运行，它知道结果的含义。例如，一些断言在失败时会抛出异常，而另一些则不会。您需要知道区别才能有效地使用它。
还有其他完善的方法来处理不良数据，包括异常处理、自定义错误消息等。
您很可能正在尝试使用与 NUnit 测试分开的 NUnit 约束语法。这是一个很好的语法，有几个人要求我们将它拆分为一个单独的包。如果我们这样做了，您可以使用它，但遗憾的是我们还没有。

【讨论】：

您好 Charlie，那么将 NUnit 项目部署到生产环境/服务器通常是不是很糟糕？我们是否应该只在本地构建上进行测试，然后在没有 NUnit 的情况下将项目发布到生产环境？或者是否有适合将 NUnit 测试项目导出到生产环境的情况？
IMO 我认为可以将 NUnit 部署到要运行测试的任何服务器上。但是，我认为您不想从任何生产代码中引用 NUnit。特别是，在 NUnit 未经认证的安全关键型应用程序中，这将是一个问题。 NUnit 是一种用于测试生产软件的工具，但并不打算成为该软件的一部分。

【解决方案2】：

您不应在生产代码中使用 NUnit 断言。如果断言失败，NUnit 断言总是抛出异常。 NUnit 不检查它是在调试还是发布（生产）中运行。 NUnit 断言也被设计为在 NUnit 测试中使用。

对于实际代码中的断言，您应该使用Debug.Assert。它的功能较少，但它会在发布模式下编译出来，因此不会使您的应用在生产中运行时崩溃。

【讨论】：

【解决方案3】：

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

至于您的第一个问题，我想说在生产代码中使用 NUnit 断言是不可接受的。问问自己，与异常或其他错误状态相比，用作断言有什么优势？

如果GLPeriodDateTime 可以是空的，这不是用户的过错，可能需要在发布之前进行更彻底的测试来解决这个问题。如果用户有错误，有更好的方法（例如异常）来通知用户错误。断言供开发人员使用。

【讨论】：

感谢您的意见。我预计它永远不会为空，因为它从中提取的字段是用户输入所必需的。不过，我仍然希望对开发人员进行检查，因为某些数据是从遗留系统导入的，虽然它“应该”始终拥有这些数据，但不检查它是不明智的。我想我会使用内置的断言让开发人员知道但不会打扰用户。