多个期望/断言来验证测试结果
我读过几本关于 TDD 和 BDD 的书和文章，认为应该避免在单个单元测试或规范中出现多个断言或期望。我也能理解这样做的原因。我仍然不确定验证复杂结果的好方法是什么。
假设被测试的方法返回一个复杂的对象作为结果（例如反序列化或数据库读取），我如何正确验证结果？
1. 对每个属性进行断言：
Assert.AreEqual(result.Property1, 1);
Assert.AreEqual(result.Property2, "2");
Assert.AreEqual(result.Property3, null);
Assert.AreEqual(result.Property4, 4.0);
2. 依赖于正确实现的 .Equals()：
Assert.AreEqual(result, expectedResult);
1. 的缺点是，如果第一个断言失败，则所有后续断言都不会运行，这些断言可能包含查找问题的有价值的信息。随着属性的变化，可维护性也可能是一个问题。
2. 的缺点是我似乎用这个测试测试了不止一件事。如果 .Equals() 未正确实现，我可能会得到误报或误报。另外，对于 2，我不知道如果测试失败，哪些属性实际上会有所不同，但我认为通常可以通过适当的 .ToString() 覆盖来解决这个问题。无论如何，我认为我应该避免被迫在失败的测试中使用调试器来查看差异。我应该马上就看到它。
2. 的下一个问题是它比较整个对象，即使对于某些测试只有某些属性可能很重要。
在 TDD 和 BDD 中，什么是合适的方法或最佳实践？
I have read in several book and articles about TDD and BDD that one should avoid multiple assertions or expectations in a single unit test or specification. And I can understand the reasons for doing so. Still I am not sure what would be a good way to verify a complex result.
Assuming a method under test returns a complex object as a result (e.g. deserialization or database read) how do I verify the result correctly?
1.Asserting on each property:
Assert.AreEqual(result.Property1, 1);
Assert.AreEqual(result.Property2, "2");
Assert.AreEqual(result.Property3, null);
Assert.AreEqual(result.Property4, 4.0);
2.Relying on a correctly implemented .Equals():
Assert.AreEqual(result, expectedResult);
The disadvantage of 1. is that if the first assert fails all the following asserts are not run, which might have contained valuable information to find the problem. Maintainability might also be a problem as Properties come and go.
The disatvantage of 2. is that I seem to be testing more than one thing with this test. I might get false positives or negatives if .Equals() is not implemented correctly. Also with 2. I do not see, what properties are actually different if the test fails but I assume that can often be addressed with a decent .ToString() override. In any case I think I should avoid to be forced to throw the debugger at the failing tests to see the difference. I should see it right away.
The next problem with 2. is that it compares the whole object even though for some tests only some properties might be significant.
What would be a decent way or best practise for this in TDD and BDD.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不要从字面上理解 TDD 建议。 “好人”的意思是，您应该在每个测试中测试一件事（以避免测试因多种原因失败并随后必须调试测试以查找原因）。
现在测试“一件事”意味着“一种行为”；恕我直言，每个测试都没有一个断言。
这是指导方针而不是规则。
所以选项：
用于比较整个数据值对象
为了比较对象的非结构化部分（任意属性集 - 这应该很少见），
Don't take TDD advice literally. What the "good guys" mean is that you should test one thing per test (to avoid a test failing for multiple reasons and subsequently having to debug the test to find the cause).
Now test "one thing" means "one behavior" ; NOT one assert per test IMHO.
It's a guideline not a rule.
So options:
For comparing whole data value objects
For comparing unstructured parts of objects (set of arbitrary properties - which should be rare),
根据问题中存在的上下文，我会选择选项 1。
它可能取决于上下文。如果我在 .NET 框架内使用某种内置的对象序列化，我可以合理地确信，如果没有遇到错误，那么整个对象都会得到适当的封送。在这种情况下，断言对象中的单个字段可能就可以了。我相信 MS 库会做正确的事情。
如果您使用 SQL 并手动将结果映射到域对象，我认为选项 1 可以比选项 2 更快地诊断某些问题。选项 2 可能依赖于 toString 方法来呈现断言失败：
现在我一直在试图弄清楚 4.0/null 是什么字段。当然，我可以将字段名称放入方法中：
这对于少量属性来说很好，但由于包装等原因，开始分解大量属性。此外，
toString维护可能会变得这是一个问题，因为它需要以与equals方法相同的速率变化。当然，没有正确的答案，归根结底，这实际上取决于您的团队（或您自己）的个人偏好。
希望有帮助！
布兰登
With the context present in the question I'd go for option 1.
It likely depends on context. If I'm using some sort of built in object serialization within the .NET framework, I can be reasonably assured that if no errors were encountered then the entire object was appropriately marshaled. In that case, asserting a single field in the object is probably fine. I trust MS libraries to do the right thing.
If you are using SQL and manually mapping results to domain objects I feel that option 1 makes it quicker to diagnose when something breaks than option 2. Option 2 likely relies on
toStringmethods in order to render the assertion failure:Now I am stuck trying to figure out what field 4.0/null was. Of course I could put the field name into the method:
This is fine for small numbers of properties, but begins to break down larger numbers of properties due to wrapping, etc. Also, the
toStringmaintenance could become an issue as it needs to change at the same rate as theequalsmethod.Of course there is no correct answer, at the end of the day, it really boils down to your team's (or your own) personal preference.
Hope that helps!
Brandon
我会默认使用第二种方法。你是对的，如果
Equals()未正确实现，则会失败，但如果您实现了自定义Equals()，则也应该对其进行单元测试。第二种方法实际上更加抽象和简洁，允许您以后更轻松地修改代码，从而以同样的方式减少代码重复。假设您选择第一种方法：
Equals()会容易得多。当然，您仍然需要在预期结果中添加属性值（如果它不是默认值），但这比添加新断言要短。此外，使用第二种方法更更容易看出哪些属性实际上有所不同。您只需在调试模式下运行测试，并比较中断时的属性。
顺便说一句，您永远不应该为此使用
ToString()。我想你想说的是[DebuggerDisplay]属性？如果您只需比较某些属性，那么：
Cat与另一个Cat进行比较，但仅考虑Dog和其他动物的共同属性，请实现Cat : Animal并比较基类。I would use the second approach by default. You're right, this fails if
Equals()is not implemented correctly, but if you've implemented a customEquals(), you should have unit-tested it too.The second approach is in fact more abstract and consise and allows you to modify the code easier later, allowing in the same way to reduce code duplication. Let's say you choose the first approach:
Equals()would be much easier. Of course you have still to add a value of the property in expected result (if it's not the default value), but it would be shorter to do than adding a new assertion.Also, it is much easier to see what properties are actually different with the second approach. You just run your tests in debug mode, and compare the properties on break.
By the way, you should never use
ToString()for this. I suppose you wanted to say[DebuggerDisplay]attribute?If you have to compare only some properties, than:
Catto anotherCatbut only considering the properties common toDogand other animals, implementCat : Animaland compare the base class.尝试“每个测试行为的一个方面”而不是“每个测试一个断言”。如果您需要多个断言来说明您感兴趣的行为，请这样做。
例如，您的示例可能是
ShouldHaveSensibleDefaults。将其拆分为ShouldHaveADefaultNameAsEmptyString、ShouldHaveNullAddress、ShouldHaveAQuantityOfZero等不会读得很清楚。将合理的默认值隐藏在另一个对象中然后进行比较也无济于事。但是，我会将具有默认值的示例与从某处的某些逻辑派生的任何属性分开，例如
ShouldCalculateTheTotalQuantity。将这样的小示例移动到它们自己的方法中可以使其更具可读性。您可能还会发现对象的不同属性会被不同的上下文更改。调出每个上下文并分别查看这些属性有助于我了解上下文与结果的关系。
Dave Astels 提出了“每个测试一个断言”，现在使用短语 “行为的一个方面”，尽管他仍然发现它对 将其分开行为。我倾向于在可读性和可维护性方面犯错误，所以如果有多个断言具有务实意义，我会这样做。
Try "one aspect of behavior per test" rather than "one assertion per test". If you need more than one assertion to illustrate the behavior you're interested in, do that.
For instance, your example might be
ShouldHaveSensibleDefaults. Splitting that up intoShouldHaveADefaultNameAsEmptyString,ShouldHaveNullAddress,ShouldHaveAQuantityOfZeroetc. won't read as clearly. Nor will it help to hide the sensible defaults in another object then do a comparison.However, I would separate examples where the values had defaults with any properties derived from some logic somewhere, for instance,
ShouldCalculateTheTotalQuantity. Moving small examples like this into their own method makes it more readable.You might also find that different properties on your object are changed by different contexts. Calling out each of these contexts and looking at those properties separately helps me to see how the context relates to the outcome.
Dave Astels, who came up with the "one assertion per test", now uses the phrase "one aspect of behavior" too, though he still finds it useful to separate that behavior. I tend to err on the side of readability and maintainability, so if it makes pragmatic sense to have more than one assertion, I'll do that.