我应该对构造函数进行单元测试吗？假设我有一个这样的构造函数：
IMapinfoWrapper wrapper;
public SystemInfo(IMapinfoWrapper mapinfoWrapper)
{
this.wrapper = mapinfoWrapper;
}
我需要为此构造器编写单元测试吗？我没有任何包装变量的 getter，所以我不需要测试它。
【问题讨论】：
标签： c# .net unit-testing constructor
没有。它的功能将由该类的所有其他单元测试进行测试。
【讨论】：
是的。如果您的构造函数中有逻辑，则应该对其进行测试。简单地设置属性不是逻辑 IMO。条件、控制流等 IS 逻辑。
编辑： 如果需要该依赖项，您可能应该测试 IMapinfoWrapper 何时为空。如果是这样，那么这就是逻辑，你应该有一个测试来捕获你的 ArgumentNullException 或其他什么......你的测试是定义代码行为方式的规范。如果它抛出 ArgumentNullException，那么应该在测试中指定。
【讨论】：
单元测试是关于测试对象的公共状态、行为和交互。
如果你只是在构造函数中设置一个私有字段，有什么要测试的？
不要费心对简单的访问器和修改器进行单元测试。这很愚蠢，对任何人都没有帮助。
【讨论】：
checkArgumnt 怎么办（可能是为了测试对象是否为空）？值得测试吗？
我相信 100% 的覆盖率。此外，100% 的覆盖率不是通过简单地通过模拟事物或设置和获取事物来测试简单的交互，而是通过更多的集成/验收测试来检查功能。因此，如果您最终编写了非常好的集成/验收测试，则应该调用您的所有构造函数（以及简单的方法，例如 setter 和 getter）。
【讨论】：
100% coverage of that you believe to be the system's functional paths. 换句话说：不是 100%
SystemInfo 实例的什么行为取决于wrapper 的值？
如果出现任何问题（例如 null 值导致损坏），那么我建议编写描述每种此类情况的场景并使用它们来驱动适当单元测试的定义。
如果所有场景最终都依赖于 IMapinfoWrapper 的私有实例的状态或行为，那么我建议改为在该类上编写单元测试。
【讨论】：
单元测试是关于检查执行路径，通常称为Cyclomatic Complexity
如果您没有路径可供选择，没有 if、没有循环、没有 GOTO (=P)，它就不是很有用
【讨论】：
问：如果在构造函数中设置成员变量，为什么要设置呢？
答：因为你有一个失败的单元测试，只有在构造函数中设置它才能通过。
如果您使用这种逻辑，您只编写代码以使单元测试通过（测试驱动开发），那么您已经有了问题的答案。
【讨论】：
除非您正在编写编译器，否则不会，因为您只会测试编译器是否可以生成代码来执行分配，这通常是没有意义的。
现在，在更常见的情况下，如果您想用包装器做其他事情，那么也许有一点。例如，如果您尝试传递 null，则可以抛出 ArgumentNullException，理论上，这可以进行单元测试。即便如此，测试的价值也很小。
就个人而言，我几乎从不明确测试构造函数。如果它们复杂到需要测试，我倾向于觉得代码有点臭。
【讨论】：
如果构造函数包含一些逻辑，比如初始化一个类，我认为你应该测试这个构造函数。或者你可以告诉开发者，将初始化放在构造函数中会降低被测代码的可测试性。
【讨论】：
在许多受 FDA 监管的环境中，必须对更关键的代码进行 100% 测试...包括类的构建。因此，有时需要对构造函数进行测试，而不管是否要测试它们。此外，使用静态分析工具的公司将需要确保一个类的所有数据成员都正确初始化，以便没有错误，尽管代码可以顺利运行并且没有错误。通常数据成员初始化是在构造函数中完成的……只是值得深思。
【讨论】：
测试访问器和修改器也是必要的，除非开发人员确保不能更改任何状态逻辑。例如，如果使用 Singleton 的设计模式，通常会使用访问器或属性，并且如果未初始化类，则从访问器完成，因为构造函数是私有的。在 C++ 中，可以将它们的函数设为 const 或 static，其中类的数据成员不能更改。 （注意：即使使用 static 也有一点风险，因为这些变量通常是全局的。）但是，如果没有测试，如果有人没有使用预防措施，你怎么能保证 100% 准确，写的东西不会成为失败时间？维护并非万无一失。
【讨论】：
视情况而定。
我不会为您给出的示例如此简单的事情编写专用的构造函数测试。
但是，如果您在构造函数中进行了逻辑测试，例如参数验证，那么可以，绝对可以。尽管像原始海报一样，如果可能的话，我不会在构造函数中进行任何工作，但通常必须进行参数验证。在这种情况下，不可避免地要阻止构造函数进行一些工作。如果构造函数中存在逻辑，则总是有可能出错，因此我将其视为任何其他方法调用并进行适当的测试。
【讨论】：
你绝对应该测试构造函数。如果你有一个默认构造函数，你应该测试它是否可以被调用。如果以后类被改变了——也许它变成了一个单例或者默认构造函数被删除以支持一个需要参数的类怎么办？在这种情况下，测试应该失败以提醒该更改（以便可以修复类或测试以满足新要求）。
默认构造函数的存在是一个需要测试的要求。即使构造函数所做的只是设置将在其他地方测试的私有成员，也应该测试存在无参数构造函数的事实。
【讨论】：
我认为答案是“是”。
那里有大量的代码假设，可怕的是，一个初始化的对象状态，而不是一个空引用——通常是在构造函数中没有分配明确的值时。
我很高兴在初始化的公共成员值发生更改时让构造函数测试中断以提醒我。这是关于防御性测试的 - 我很务实，并且比没有测试更快乐，当它们被证明无用或无用时将其删除。
【讨论】：
我正在测试包含逻辑的构造函数——例如验证或有条件地设置私有状态。验证错误最终会导致构造函数抛出异常。成功的执行最终会创建一个对象，该对象根据构造函数中设置的状态表现出特定的行为。 无论哪种方式，它都需要测试。但是构造函数测试很无聊，因为它们看起来都一样——调用构造函数，做出断言。测试方法声明通常比整个测试逻辑占用更多的空间......所以我写了一个简单的测试库来帮助为构造函数编写声明性测试：How to Easily Test Validation Logic in Constructors in C#
这是一个示例，我在一个类的构造函数上尝试了七个测试用例：
[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();
}
通过这种方式，我可以为我的构造函数测试所有相关案例，而无需输入太多内容。
【讨论】：