C# 对构造函数进行单元测试很重要吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/357929/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it important to unit test a constructor?
提问by Nathan W
Ought I to unit test constructors? Say I have a constructor like this:
我应该对构造函数进行单元测试吗？假设我有一个这样的构造函数：
IMapinfoWrapper wrapper;
public SystemInfo(IMapinfoWrapper mapinfoWrapper)
{
this.wrapper = mapinfoWrapper;
}
Do I need to write a unit test for this construtor? I don't have any getters for the wrapper variable, so I don't need to test that.
我需要为此构造函数编写单元测试吗？我没有任何包装器变量的吸气剂，所以我不需要测试。
采纳答案by yfeldblum
Unit testing is about testing the public states, behaviors, and interactions of your objects.
单元测试是关于测试对象的公共状态、行为和交互。
If you simply set a private field in your constructor, what is there to test?
如果您只是在构造函数中设置一个私有字段，那么有什么可测试的？
Don't bother unit-testing your simple accessors and mutators. That's just silly, and it doesn't help anyone.
不要费心对简单的访问器和修改器进行单元测试。这只是愚蠢的，它对任何人都没有帮助。
回答by Draemon
No. Its functionality will be tested by every other unit test on the class.
不可以。它的功能将由类上的每个其他单元测试进行测试。
回答by Brian Genisio
Yes. If you have logic in your constructor, you should test it. Simply setting properties is not logic IMO. Conditionals, control flow, etc IS logic.
是的。如果你的构造函数中有逻辑，你应该测试它。简单地设置属性不是逻辑 IMO。条件、控制流等是逻辑。
Edit:You should probably test for when IMapinfoWrapper is null, if that dependency is required. If so, then that is logic and you should have a test that catches your ArgumentNullException or whatever... your tests are specifications that define how the code behaves. If it throws an ArgumentNullException, then that should be specified in a test.
编辑：如果需要该依赖项，您可能应该测试 IMapinfoWrapper 何时为空。如果是这样，那么这就是逻辑，您应该有一个测试来捕获您的 ArgumentNullException 或其他什么……您的测试是定义代码行为方式的规范。如果它抛出 ArgumentNullException，那么应该在测试中指定。
回答by digiarnie
I believe in 100% coverage. Also 100% coverage not by simply testing simple interactions by mocking things or just setting and getting things, but more integration/acceptance tests that check functionality. So if you end up writing really good integration/acceptance tests, all of your constructors (and simple methods such as setters and getters) should be called.
我相信 100% 的覆盖率。同样 100% 的覆盖率不是简单地通过模拟事物或只是设置和获取事物来测试简单的交互，而是更多的集成/验收测试来检查功能。因此，如果您最终编写了非常好的集成/验收测试，则应该调用所有构造函数（以及简单的方法，例如 setter 和 getter）。
回答by joel.neely
What behavior of an instance of SystemInfodepends on the value of wrapper?
的实例的什么行为SystemInfo取决于 的值wrapper？
If anything can go wrong (e.g. null value causes breakage) then I suggest writing scenarios describing each such situation and using them to drive the definition of the appropriate unit tests.
如果任何事情都可能出错（例如空值导致损坏），那么我建议编写描述每种情况的场景并使用它们来驱动适当单元测试的定义。
If all of the scenarios end up being dependent on the state or behavior of the private instance of IMapinfoWrapper, then I'd suggest writing unit tests on that class instead.
如果所有场景最终都依赖于 的私有实例的状态或行为IMapinfoWrapper，那么我建议改为对该类编写单元测试。
回答by Eric
Unit Testing is about checking paths of execution, something often refered as Cyclomatic Complexity
单元测试是关于检查执行路径，通常称为圈复杂度
If you have no path to choose from, no if, no loop, no GOTO (=P) its not very useful
如果你没有路径可供选择，没有 if，没有循环，没有 GOTO (=P) 它不是很有用
回答by John Sonmez
Q: If you are setting a member variable in the constructor, why are you setting it.
Q：如果在构造函数中设置成员变量，为什么要设置它。
A: Because you have a failing unit test that can only be made to pass by setting it in the constructor.
A: 因为你有一个失败的单元测试，只能通过在构造函数中设置它才能通过。
If you use this logic, where you only write code to cause a unit test to pass (Test Driven Development), then you will already have the answer to your question.
如果您使用这种逻辑，您只编写代码来使单元测试通过（测试驱动开发），那么您就已经有了问题的答案。
回答by Jim Cooper
Not unless you're writing a compiler, because you would only be testing that the compiler could generate code to do assignments, which is normally pointless.
除非您正在编写编译器，否则不会，因为您只会测试编译器是否可以生成代码来进行赋值，这通常是毫无意义的。
Now, in a more usual situation, if you want to do something else with the wrapper, then maybe there's a point. For example, you could throw an ArgumentNullException if you tried to pass a null, and in theory, that could have a unit test. Even then, the value of the test is pretty minimal.
现在，在更常见的情况下，如果您想用包装器做其他事情，那么也许有一点。例如，如果您尝试传递空值，您可能会抛出 ArgumentNullException，并且理论上，这可能有一个单元测试。即便如此，测试的价值也非常小。
Personally, I almost never explicitly test constructors. If they are complicated enough to need tests, I tend to feel the code is a little on the smelly side.
就个人而言，我几乎从不明确测试构造函数。如果它们复杂到需要测试，我往往会觉得代码有点臭。
回答by Magus
If the constructor contains some logic, such as initialize a class, I think you should test the very constructor. Or you can talk to the developer that putting initialization in the constructor will cut the testability of code under test.
如果构造函数包含一些逻辑，比如初始化一个类，我认为你应该测试这个构造函数。或者您可以与开发人员交谈，将初始化放在构造函数中会降低被测代码的可测试性。
回答by Brandon
In many FDA-regulated environments, more critical code must be 100% tested...including the construction of classes. So, the testing of constructors is sometimes necessary regardless of reasoning to or not to test them. Also, companies that use static analysis tools will need to make sure ALL data members of a class are properly initialized in order to not have errors although the code may run smoothly and free of errors. Usually data member initialization is done in the constructor...just food for thought.
在许多 FDA 监管的环境中，更关键的代码必须经过 100% 测试……包括类的构建。因此，有时需要对构造函数进行测试，而不管是否要测试它们。此外，使用静态分析工具的公司需要确保类的所有数据成员都被正确初始化，以便没有错误，尽管代码可能运行顺利且没有错误。通常数据成员初始化是在构造函数中完成的……只是值得深思。
