blocks|key|1670829|text|单元测试是关于测试对象的公共状态、行为和交互的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1670830|如果您只是在构造函数中设置了一个私有字段，那么有什么需要测试的呢？|1670831|不要费心对简单的存取器和变更器进行单元测试。这太愚蠢了，而且对任何人都没有帮助。|1670832|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|1671074|text|问:如果要在构造函数中设置成员变量，为什么要设置它？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1671075|答:因为你有一个失败的单元测试，只有在构造函数中设置它才能通过。|1671076|如果你使用这个逻辑，你只需要编写代码来使单元测试通过(测试驱动开发)，那么你就已经有了问题的答案。|1671077|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|1455847|text|不是的。它的功能将通过类上的其他单元测试进行测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1455848|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|1671393|text|你绝对应该测试构造器。如果你有一个默认的构造函数，你应该测试它是否可以被调用。如果后来类被更改了--可能它变成了单例，或者缺省构造函数被删除了，取而代之的是需要参数的构造函数，那该怎么办？在这种情况下，测试应该失败，以警告该更改(以便可以修复类或测试以满足新的需求)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1671394|默认构造函数的存在是一个应该进行测试的要求。即使构造函数所做的所有工作都是设置将在其他地方测试的私有成员，也应该测试存在无参数构造函数的事实。|1671395|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|1456451|text|当构造函数包含逻辑时，我正在测试它们--例如，验证或有条件地设置私有状态。验证错误以构造函数抛出的异常结束。成功的执行结束于对象的创建，该对象根据构造函数中设置的状态表现出特定的行为。无论哪种方式，它都需要测试。但是构造函数测试很无聊，因为它们看起来都一样--调用构造函数，进行断言。测试方法声明通常比整个测试逻辑占用更多的空间……因此，我编写了一个简单的测试库来帮助为构造函数编写声明性测试：How+to+Easily+Test+Validation+Logic+in+Constructors+in+C#|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1456452|以下是我在一个类的构造函数上尝试七个测试用例的示例：|1456453|[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|1456454|通过这种方式，我可以测试我的构造函数的所有相关用例，而不需要输入太多内容。|1456455|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.

blocks|key|1671261|text|在许多FDA规定的环境中，更关键的代码必须100%25+tested...including类的构造。因此，对构造函数的测试有时是必要的，无论是否对其进行测试。此外，使用静态分析工具的公司将需要确保类的所有数据成员都已正确初始化，以便不会出现错误，尽管代码可能会流畅地运行且没有错误。通常，数据成员的初始化是在constructor...just中完成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1671262|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|1671419|text|我想答案是肯定的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1671420|有很多代码假设了一个初始化的对象状态，而不是一个空引用--通常在构造函数中没有显式赋值的情况下。|1671421|当初始化的公共成员值被更改时，我很高兴有构造函数测试中断来提醒我。这是关于防御性测试的--我是务实的，有测试比没有测试更开心，当它们被显示为没有帮助或有用时，我会删除它们。|1671422|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|1670882|text|我相信100%25的覆盖率。另外，100%25的覆盖率不是通过简单的模拟东西或只是设置和获取东西来测试简单的交互，而是通过更多的集成/验收测试来检查功能。因此，如果您最终编写了非常好的集成/验收测试，则应该调用所有的构造函数(以及setter和getter等简单方法)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1670883|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|1456357|text|测试访问器和变更器也是必要的，除非开发人员已经确保不能更改任何状态逻辑。例如，如果使用Singleton的设计模式，通常会使用访问器或属性，如果类没有初始化，则由访问器完成，因为构造函数是私有的。在C%2B%2B中，可以将函数设为常量或静态，其中类的数据成员不能更改。(注意:即使使用静态也有点风险，因为这些变量通常是全局变量。)然而，如果没有测试，如果有人未能使用预防措施，您如何以100%25的准确性保证所编写的内容不会随着时间的推移而失败？维护并不是万无一失的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1456358|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|1456002|text|SystemInfo实例的什么行为取决于wrapper的值|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1456003|如果有任何地方会出错(例如，空值会导致破坏)，那么我建议编写描述每种情况的场景，并使用它们来驱动适当单元测试的定义。|1456004|如果所有场景最终都依赖于IMapinfoWrapper私有实例的状态或行为，那么我建议在该类上编写单元测试。|1456005|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|1671148|text|除非你正在编写一个编译器，因为你只是在测试编译器是否可以生成代码来进行赋值，这通常是没有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1671149|现在，在更常见的情况下，如果您想对包装器做一些其他的事情，那么也许是有意义的。例如，如果您试图传递一个null，那么可以抛出一个ArgumentNullException，理论上，这可以有一个单元测试。即使这样，测试的价值也是非常小的。|1671150|就我个人而言，我几乎从不显式测试构造函数。如果它们足够复杂，需要测试，我倾向于觉得代码有点难闻。|1671151|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|1671193|text|如果构造函数包含一些逻辑，比如初始化一个类，我认为你应该测试这个构造函数。或者你可以告诉开发人员，把初始化放在构造函数中会降低被测代码的可测试性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1671194|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|1456067|text|单元测试是关于检查执行路径的，通常被称为Cyclomatic+Complexity|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1456068|如果你没有路径可供选择，no+if，no+loop，no+GOTO+(=P)都不是很有用|1456069|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

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?

单元测试

验收测试

编译器

我应该对构造函数进行单元测试吗？假设我有一个这样的构造函数：IMapinfoWrapper wrapper;public SystemInfo(IMapinfoWrapper mapinfoWrapper){    this.wrapper = mapinfoWrapper;}我需要为这个构造器写一个单元测试吗？我没有任何用于包装器变量的getter方法，所以我不需要测试它。

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

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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