blocks|key|917666|text|不是的。它的功能将通过类上的其他单元测试进行测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|917667|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No. Its functionality will be tested by every other unit test on the class.

blocks|key|110612|text|是。如果你的构造函数中有逻辑，你应该对其进行测试。简单地设置属性不是逻辑上的IMO。条件、控制流等都是逻辑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|110613|编辑:如果需要依赖关系，您可能应该测试一下IMapinfoWrapper是否为null。如果是这样，那么这就是逻辑，你应该有一个测试来捕获你的ArgumentNullException或其他东西……您的测试是定义代码行为方式的规范。如果它抛出一个ArgumentNullException，那么应该在测试中指定它。|offset|length|style|BOLD|110614|entityMap^0|0|0|4D|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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. 

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.

blocks|key|110628|text|单元测试是关于测试对象的公共状态、行为和交互的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|110629|如果您只是在构造函数中设置了一个私有字段，那么有什么需要测试的呢？|110630|不要费心对简单的存取器和变更器进行单元测试。这太愚蠢了，而且对任何人都没有帮助。|110631|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|4174377|text|我相信100%25的覆盖率。另外，100%25的覆盖率不是通过简单的模拟东西或只是设置和获取东西来测试简单的交互，而是通过更多的集成/验收测试来检查功能。因此，如果您最终编写了非常好的集成/验收测试，则应该调用所有的构造函数(以及setter和getter等简单方法)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4174378|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|4174410|text|SystemInfo实例的什么行为取决于wrapper的值|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4174411|如果有任何地方会出错(例如，空值会导致破坏)，那么我建议编写描述每种情况的场景，并使用它们来驱动适当单元测试的定义。|4174412|如果所有场景最终都依赖于IMapinfoWrapper私有实例的状态或行为，那么我建议在该类上编写单元测试。|4174413|entityMap^0|0|A|K|7|0|0|C|F|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|K|$]]

What behavior of an instance of <code>SystemInfo</code> depends on the value of <code>wrapper</code>?

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 <code>IMapinfoWrapper</code>, then I'd suggest writing unit tests on that class instead.

blocks|key|4174425|text|单元测试是关于检查执行路径的，通常被称为Cyclomatic+Complexity|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4174426|如果你没有路径可供选择，no+if，no+loop，no+GOTO+(=P)都不是很有用|4174427|entityMap|0|LINK|mutability|MUTABLE|url|http://www.lexjansen.com/pharmasug/2004/FDACompliance/FC06.pdf^0|K|L|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Unit Testing is about checking paths of execution, something often refered as <a href="http://www.lexjansen.com/pharmasug/2004/FDACompliance/FC06.pdf" rel="nofollow noreferrer">Cyclomatic Complexity</a>

If you have no path to choose from, no if, no loop, no GOTO (=P) its not very useful

blocks|key|922105|text|问:如果要在构造函数中设置成员变量，为什么要设置它？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|922106|答:因为你有一个失败的单元测试，只有在构造函数中设置它才能通过。|922107|如果你使用这个逻辑，你只需要编写代码来使单元测试通过(测试驱动开发)，那么你就已经有了问题的答案。|922108|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Q: If you are setting a member variable in the constructor, why are you setting it.

A: Because you have a failing unit test that can only be made to pass by setting it in the constructor.

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.

blocks|key|110761|text|除非你正在编写一个编译器，因为你只是在测试编译器是否可以生成代码来进行赋值，这通常是没有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|110762|现在，在更常见的情况下，如果您想对包装器做一些其他的事情，那么也许是有意义的。例如，如果您试图传递一个null，那么可以抛出一个ArgumentNullException，理论上，这可以有一个单元测试。即使这样，测试的价值也是非常小的。|110763|就我个人而言，我几乎从不显式测试构造函数。如果它们足够复杂，需要测试，我倾向于觉得代码有点难闻。|110764|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

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.

blocks|key|110789|text|如果构造函数包含一些逻辑，比如初始化一个类，我认为你应该测试这个构造函数。或者你可以告诉开发人员，把初始化放在构造函数中会降低被测代码的可测试性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|110790|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|110811|text|在许多FDA规定的环境中，更关键的代码必须100%25+tested...including类的构造。因此，对构造函数的测试有时是必要的，无论是否对其进行测试。此外，使用静态分析工具的公司将需要确保类的所有数据成员都已正确初始化，以便不会出现错误，尽管代码可能会流畅地运行且没有错误。通常，数据成员的初始化是在constructor...just中完成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|110812|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|110854|text|测试访问器和变更器也是必要的，除非开发人员已经确保不能更改任何状态逻辑。例如，如果使用Singleton的设计模式，通常会使用访问器或属性，如果类没有初始化，则由访问器完成，因为构造函数是私有的。在C%2B%2B中，可以将函数设为常量或静态，其中类的数据成员不能更改。(注意:即使使用静态也有点风险，因为这些变量通常是全局变量。)然而，如果没有测试，如果有人未能使用预防措施，您如何以100%25的准确性保证所编写的内容不会随着时间的推移而失败？维护并不是万无一失的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|110855|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Testing accessors and mutators is also necessary unless the developer has ensured that no state logic can be changed. For instance, if one uses the design pattern for a Singleton, often times accessors or properties are used, and if the class is not initialized, it is done from the accessor since the constructor is private. In C++, one can make their functions const or static in which data members of the class cannot be changed. (Note: Even using static is a bit risky since those variables are often global.) However, without a test, if someone fails to use preventative measures, how can you guarantee with a 100% accuracy that what is written cannot become a failure over time? Maintenance is hardly foolproof.

blocks|key|3328953|text|那得看情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3328954|对于像你给出的例子这样简单的东西，我不会费心去写一个专门的构造函数测试。|3328955|但是，如果在构造函数中有逻辑测试，比如参数验证，那么绝对可以。虽然，像最初的发帖者一样，如果可能的话，我不会在构造函数中做任何工作，但必须进行参数验证是很常见的。在这种情况下，不可避免地要阻止构造函数执行某些工作。如果构造函数中有逻辑，那么它总是有可能出错，因此我将其视为任何其他方法调用，并对其进行适当的测试。|3328956|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It depends.

I wouldn't bother writing a dedicated constructor test for something so simple as the example you gave. 

However, if you have logical tests in the constructor such as a parameter validation, then yes, absolutely. Although, like the original poster, I do no work in the constructor if possible, it's common that parameter validation must be done. In this case it is unavoidable to keep the constructor from doing some work. If there's logic in the constructor, there's always the chance that it could be wrong, hence I treat it just like any other method call and test it appropriately.

blocks|key|4174659|text|你绝对应该测试构造器。如果你有一个默认的构造函数，你应该测试它是否可以被调用。如果后来类被更改了--可能它变成了单例，或者缺省构造函数被删除了，取而代之的是需要参数的构造函数，那该怎么办？在这种情况下，测试应该失败，以警告该更改(以便可以修复类或测试以满足新的需求)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4174660|默认构造函数的存在是一个应该进行测试的要求。即使构造函数所做的所有工作都是设置将在其他地方测试的私有成员，也应该测试存在无参数构造函数的事实。|4174661|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You absolutely should test the constructor. If you have a default constructor, you should test that it can be called. What if later on the class is changed--perhaps it becomes a singleton or the default constructor is removed in favor of one requiring parameters? The test should fail in that case to alert that change (so that the class or the test can be fixed to meet the new requirement).

The presence of a default constructor is a requirement that should have a test. Even if all the constructor does is set private members that will be tested elsewhere, the fact that there is a parameterless constructor should be tested.

blocks|key|3329114|text|我想答案是肯定的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3329115|有很多代码假设了一个初始化的对象状态，而不是一个空引用--通常在构造函数中没有显式赋值的情况下。|3329116|当初始化的公共成员值被更改时，我很高兴有构造函数测试中断来提醒我。这是关于防御性测试的--我是务实的，有测试比没有测试更开心，当它们被显示为没有帮助或有用时，我会删除它们。|3329117|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think the answer to this is "Yes".

There's plenty of code out there which assumes, horribly, an initialised object state, instead of a null reference - often when there are no explicit values assigned in the constructor.

I am happy to have constructor tests break to alert me when initialised public member values have been changed. This is about defensive testing - I'm pragmatic, and happier to have tests than not, and remove them when they're shown to not be helpful or useful.

blocks|key|3329151|text|当构造函数包含逻辑时，我正在测试它们--例如，验证或有条件地设置私有状态。验证错误以构造函数抛出的异常结束。成功的执行结束于对象的创建，该对象根据构造函数中设置的状态表现出特定的行为。无论哪种方式，它都需要测试。但是构造函数测试很无聊，因为它们看起来都一样--调用构造函数，进行断言。测试方法声明通常比整个测试逻辑占用更多的空间……因此，我编写了一个简单的测试库来帮助为构造函数编写声明性测试：How+to+Easily+Test+Validation+Logic+in+Constructors+in+C#|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3329152|以下是我在一个类的构造函数上尝试七个测试用例的示例：|3329153|[TestMethod]
public+void+Constructor_FullTest()
{

++++IDrawingContext+context+=+new+Mock<IDrawingContext>().Object;+

++++ConstructorTests<Frame>
++++++++.For(typeof(int),+typeof(int),+typeof(IDrawingContext))
++++++++.Fail(new+object[]+{+-3,+5,+context+},+typeof(ArgumentException),+"Negative++length")
++++++++.Fail(new+object[]+{+0,+5,+context+},+typeof(ArgumentException),+"Zero+length")
++++++++.Fail(new+object[]+{+5,+-3,+context+},+typeof(ArgumentException),+"Negative+width")
++++++++.Fail(new+object[]+{+5,+0,+context+},+typeof(ArgumentException),+"Zero+width")
++++++++.Fail(new+object[]+{+5,+5,+null+},+typeof(ArgumentNullException),+"Null+drawing+context")
++++++++.Succeed(new+object[]+{+1,+1,+context+},+"Small+positive+length+and+width")
++++++++.Succeed(new+object[]+{+3,+4,+context+},+"Larger+positive+length+and+width")
++++++++.Assert();

}|code-block|syntax|javascript|3329154|通过这种方式，我可以测试我的构造函数的所有相关用例，而不需要输入太多内容。|3329155|entityMap|0|LINK|mutability|MUTABLE|url|http://codinghelmet.com/articles/constructor-tests^0|5H|1L|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|Z|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

I am testing constructors when they contain logic - e.g. validation or conditional setting a private state. Validation errors end up in an exception thrown from the constructor. Successful execution ends up in a creation of object which exhibits specific behavior depending on the state which was set in the constructor.
In either way, it requires testing. But constructor tests are boring because they all look the same - invoke the constructor, make an assertion. Test method declarations often take more space than the whole testing logic... So I wrote a simple testing library which helps write declarative tests for the constructors: <a href="http://codinghelmet.com/articles/constructor-tests" rel="nofollow noreferrer">How to Easily Test Validation Logic in Constructors in C#</a>

Here is an example in which I am trying seven test cases on a constructor of one class:

<pre><code>[TestMethod]
public void Constructor_FullTest()
{

 IDrawingContext context = new Mock&lt;IDrawingContext&gt;().Object; 

 ConstructorTests&lt;Frame&gt;
 .For(typeof(int), typeof(int), typeof(IDrawingContext))
 .Fail(new object[] { -3, 5, context }, typeof(ArgumentException), "Negative length")
 .Fail(new object[] { 0, 5, context }, typeof(ArgumentException), "Zero length")
 .Fail(new object[] { 5, -3, context }, typeof(ArgumentException), "Negative width")
 .Fail(new object[] { 5, 0, context }, typeof(ArgumentException), "Zero width")
 .Fail(new object[] { 5, 5, null }, typeof(ArgumentNullException), "Null drawing context")
 .Succeed(new object[] { 1, 1, context }, "Small positive length and width")
 .Succeed(new object[] { 3, 4, context }, "Larger positive length and width")
 .Assert();

}
</code></pre>

In this way, I can test all the relevant cases for my constructor without typing much.

Ought I to unit test constructors? Say I have a constructor like this:

<pre><code>IMapinfoWrapper wrapper;
public SystemInfo(IMapinfoWrapper mapinfoWrapper)
{
 this.wrapper = mapinfoWrapper;
}
</code></pre>

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.

Is it important to unit test a constructor?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我应该对构造函数进行单元测试吗？假设我有一个这样的构造函数：IMapinfoWrapper wrapper;public SystemInfo(IMapinfoWrapper mapinfoWrapper){    this.wrapper = mapinfoWrapper;}我需要为这个构造器写一个单元测试吗？我没有...

问对构造函数进行单元测试很重要吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对构造函数进行单元测试很重要吗？EN