断言是否应该保留在测试版本中答案

【问题标题】：should asserts remain in the testing version断言是否应该保留在测试版本中
【发布时间】：2013-11-01 20:35:35
【问题描述】：

在开发过程中使用断言的主题在 SO 上得到了广泛的介绍。代码有三个条件：

1) Development
2) Testing
3) Production

断言存在于开发版本中，并从生产版本中删除。但是我发现了任何说它们应该在测试版本中保留还是删除的内容？有什么想法吗？

【问题讨论】：

【解决方案1】：

如果您从 .NET 开发任何东西，例如 MFC 或 C#，那么 ASSERTS 将不会包含在发布版本中，您不必进行任何修改。如果出现任何错误（这将 ;) ），请将它们留给更好的调试。至于 JS 和 PHP，我会说日志更好，因为与开发人员消息一起弹出的断言或警报看起来非常糟糕且令人费解。

P.S>所有观点均为个人观点

【讨论】：

【解决方案2】：

意见：如果你分手测试：

【讨论】：

【解决方案3】：

我从不写asserts。相反，我对真实的生产代码进行单元测试和集成测试等。

我不喜欢使用assert，因为它们检测问题的能力有些有限，而且我对意外的副作用感到偏执。

我非常不喜欢在代码中使用条件来根据构建标志（例如开发与生产）来编译或编译某些内容。这些条件只会使代码复杂化，并且它们必须有可能使您测试的代码与生产中的代码不同。

我个人的感觉是，应该在实际业务模块中编写的唯一代码是生产级代码，所有测试都应该针对它进行。不得出于测试目的对业务模型进行任何更改。即，如果您想测试某些东西，请将其设为public 并为其编写外部测试。

【讨论】：

完全同意避免条件调试代码与生产代码混合。就在前几天，我出于紧急情况对这条规则做了一个例外，这让我很难过：调试代码有微妙的、意想不到的副作用，所以我测试的（启用调试代码）没有错误，但实际的生产代码有新的错误。
@syam，断言应该从生产版本中删除。并且断言不应包含任何可能在删除断言时影响应用程序的逻辑。
约翰，感谢您的回答。我对断言没有太多经验，但大多数人都同意应该使用它们。 Code Complete 表示它们应该用于测试在开发过程中绝不应该发生的错误
@Maximus 我的观点（约翰也是）是，即使调试代码不应该影响程序的状态，但在复杂的系统中，有时它会无意中影响。然后，当您将其移除以进行生产时，所有地狱都会崩溃。外部测试更可靠。
@Maximus：我不确定“大多数人”，但我可以告诉你 Code Complete 是否建议使用断言，那么我不同意 Code Complete。我的建议来自 20 年编写生产系统的经验。我还要指出，Code Complete 是在另一个时代编写的——早在单元测试流行之前。