Question

考虑：

class MyClass<T> where T : class
{
}

在这种情况下，where子句强制执行MyClass只是引用类型的通用规范。

理想情况下，我应该有一个单元测试来测试这个规范。但是，这个单元测试显然不起作用，但它解释了我想要实现的目标：

[Test]
[DoesNotCompile()]
public void T_must_be_a_reference_type()
{
    var test = new MyClass<int>();
}

我可以做些什么来测试不允许代码编译实现的规范？

修改：

更多信息：好的，所以我这样做的理由（哈哈）是我一直在遵循TDD方法，除非你有一个失败的单元测试，否则你不能编写任何代码。假设你有这个：

class MyClass<T> { }

除非T是班级，否则你可以写什么测试会失败？像default(T) == null？

这样的东西

进一步编辑：

因此，在对此进行“根本原因分析”之后，问题在于我以隐式方式依赖于此类消费者中的default(T) null。我能够将该消费者代码重构为另一个类，并在那里指定一个泛型类型限制（将其限制为class），如果有人要删除我正在谈论的类的限制，这会有效地使代码无法编译大约在上面。

Answer 1

为什么你需要进行单元测试？您是否为

等方法编写了单元测试

public void Foo(string x)

检查它只能接受字符串，而不是整数？如果没有，你认为差异是什么？

编辑：只是稍微不那么异想天开：在这种情况下，规范由声明验证。测试通常应该测试行为。这是我喜欢的代码合同之一：我觉得没有必要对合同进行单元测试，除非它们表达了复杂的东西 - 在这种情况下，我要测试的是复杂性，而不是“合同强制执行”

编辑：回复编辑问题：

除非T是一个班级，否则你可以写什么测试会失败？

你可以写一些类似的东西：

Type definition = typeof(MyClass<>);
Assert.Throws<ArgumentException>(() => definition.MakeGenericType(typeof(int)));

然而，这似乎违背了测试的真正目的......

Answer 2

您不应该测试编译器是否正常工作。如果在代码中指定它，这就足够了。从代码的角度来看，这与此基本相同：

[Test]
public void Test_whether_add_works()
{
    int i = 1 + 2;

    Assert.AreEqual(3, i);
}

Answer 3

这是一个很好的问题！非常同意您的测试驱动方法。你正在努力的实际上是两种范式的冲突。旧程序应该证明程序应该被证明是正确的，使用数学而不运行它们（我们专业的数学祖先遗产）和程序化的新范例应该通过执行示例用例（即测试）来证明是正确的。所以你要尝试的是将新范式的实践应用于旧范例的工件，当然这不会真正起作用......

更多关于类型和测试的二分法，请参阅Chris Smith撰写的这篇优秀文章，http://web.archive.org/web/20080822101209/http://www.pphsg.org/cdsmith/types.html

Answer 4

你在写一个正确的单元测试吗？看起来你要测试C＃编译器而不是你的代码。

如何为“T必须是参考类型”编写单元测试？

4 个答案: