FluentAssertions应该用于生产代码吗？

Question

我一直在使用FluentAssertions进行单元测试，并想知道为什么在这种情况下才会提到它。如果您通常使用防护编写快速失败的生产代码，则必须复制FluentAssertions已经提供的一些功能。我可以想到不使用它的一些原因：

1. 它的重点是可读性，而不是表现良好。计数器：不是那些高级语言也做了什么，并且与不做过早优化的警告有关？
2. 还与性能有关，在发布模式下编译代码时，没有好的方法可以运行某些断言。计数器：您可以删除您认为在生产中不会发生的断言，但会导致难以追踪的异常。只要它们不会显着影响性能，请保留它。
3. 它的断言并不总是抛出标准异常。例如，ArgumentNullException和ArgumentException无处不在且预期，但FluentAssertions不知道您正在测试参数并抛出一般异常。

也许已经知道性能受到了很大影响所以＃1和＃2是合法的，但是你通常也需要快速的单元测试，因此可以应用相同的逻辑。是否有其他充分的理由不在生产代码中使用FluentAssertions？

Answer 1

Fluent Assertions仅提及单元测试和其他类型的测试，因为测试代码和生产应该分开。 例如。当您使用Fluent Assertions时，不应该强迫您依赖Fluent断言的测试依赖性。

如果Fluent Assertions很慢，我无法回答，问题是它是否太慢，这取决于场景。 对于单元测试，其开销远远超出可读性和改进的故障消息。 在热循环中使用Fluent Assertions可能会轻易破坏您的性能。 同样，这取决于使用Fluent Assertions中的哪个函数。例如。 BeEquivalentTo严重依赖于反思。

Debug.Assert提供另一个但相关的目的。 它声明了代码的状态，例如检查invariants。