我有一个FileExtractor类，其中Start方法执行了一些步骤。
我在我的文件夹中创建了一个名为“WhenExtractingInvalidFile.cs”的测试类，名为“FileExtractorTests”，并在其中添加了一些测试方法，如下所示，应该验证为Start（）方法的步骤：
[TestMethod]
public void Should_remove_original_file()
{
}
[TestMethod]
public void Should_add_original_file_to_errorStorage()
{
}
[TestMethod]
public void Should_log_error_locally()
{
}
这样，它可以很好地组织行为和应该满足的期望。
问题是这些测试方法的大部分逻辑是相同的，所以我应该创建一个验证所有步骤的测试方法，还是像上面那样分别进行验证？
[TestMethod]
public void Should_remove_original_file_then_add_original_file_to_errorStorage_then_log_error_locally()
{
}
最佳做法是什么？
答案 0 :(得分：2)
虽然人们普遍认为Act部分的测试应该只包含一个电话，但对于每个测试的一个断言仍然存在很多争论。实践。
我倾向于遵守它，因为：
当测试失败时，我立即知道（从测试名称）我们想要在被测方法上验证的多项内容出错了。
这些暗示嘲讽的测试比常规测试更难阅读，当你在同一测试中对多个嘲讽断言时，它们很容易变得神秘。
如果您不遵循它，我至少建议您添加有意义的断言消息，以便在测试失败时尽量减少头部划伤。
答案 1 :(得分：0)
我会做同样的事情，但使用_on_start这样的后缀：Should_remove_original_file_on_start。后一种方法只会给你最多一个断言失败，即使Start的所有方面都可能被破坏。
答案 2 :(得分：0)
干 - 不要重复自己。
考虑您的测试失败的情况。从测试组织角度来看最有用的是什么？
要考虑的第二个方面是维护。您想运行并维护1个测试或n个测试吗？不要因为编写许多没有价值的测试而过度负担开发（我认为TDD因为这个原因而有点过高）。如果测试代码的代码路径较大而不是短代码，则测试更有价值。
在这个特定的场景中，我会创建一个单独的测试。如果此测试经常失败并且您没有足够快地解决问题的根本原因，请重新考虑多个测试。