当我测试一个void方法时，没有什么可断言的。比如一个CreateSomething方法。我知道我可以在测试方法中调用FindSomething等其他方法，但无论如何，如果（在create方法中）存在错误，它将显示出来。因此，在每种方法中调用断言都是一种很好的做法，或者在没有断言的情况下我很好吗？
答案 0 :(得分：5)
但是您的测试代码至少应该执行以下其中一项：
所以你应该检查它的价值，行动和错误。有时候只是其中之一，有时你不能在没有组合的情况下做到这一点。
答案 1 :(得分：4)
Void方法通常会更改实例的状态。在这种情况下，您的测试方法应断言调用后存在预期状态。即你需要断言相关成员的状态。
无副作用的无效方法也可以使用模拟对象进行测试。在这种情况下，您将测试该方法是否对模拟对象进行了预期的调用。
虽然说类似函数的函数应该是首选的IMO，因为它们更容易推理并且更容易测试，但这只是我的观点。
答案 2 :(得分：2)
当我测试一个void方法时，没有什么可以断言。
那么，该方法的目的是什么？
回答这个问题有助于找到断言的内容。如果anwser实际上 nothing ，您应该能够从代码中删除该方法而不会产生任何影响。
实现覆盖此断言的测试代码是另一个问题，考虑到您的开发环境或项目的约束，这些问题可能是也可能不容易或相关。
答案 3 :(得分：0)
每种测试方法都没有必要assert。例如，如果您想测试您的方法将抛出异常，您可以使用ExpectedException（MS测试）。如果你没有测试你的方法抛出异常并且你没有单assert那么你可能做错了。只是调用一个方法不是一个好的单元测试。您需要以某种方式验证此方法在调用之后是否按预期执行，这通常通过断言来实现。
答案 4 :(得分：0)
好吧，如果你只需要测试该方法运行...将其包装在try和catch中，如果由于某种原因失败（并且你不能断言任何东西） - 在catch中断言（false），或者如果您期望异常 - 请使用ExpectedException ...
答案 5 :(得分：0)
你应该在每次测试中至少断言一个事实。仅仅因为您的单元测试框架将计算断言的数量，并且度量测试次数/断言次数可以给出关于测试套件的良好第一印象。
如果看似没有什么可以断言：我所知道的所有单元测试框架都有Assert.Throws/Assert.DoesNotThrow方法用于此目的。
答案 6 :(得分：0)
当然有一些像Assert.Throws / Assert.DoesNotThrow在MSTest 有Assert.Fail（）和AssertFailedException（）
答案 7 :(得分：0)
如果您的测试被破坏，请确保它失败。这可以通过以下方式见证：
也许有一些例外，但我想不出任何。 TDD的一个原则在这里很重要：
首先编写失败的测试。
如果你这样做，你可以保证这是一个很好的测试。
有些人声称每个测试应该有一个，只有一个，断言......但这是一个不同的问题。