单元测试方法\测试计数答案

【问题标题】：Unit Test Method\Test Count单元测试方法\测试计数
【发布时间】：2013-01-16 18:43:23
【问题描述】：

我有一系列单元测试来验证我的 ORM 域模型中的结构。第一个测试计算元数据中的实体数量，假设是 146 个实体。

这意味着我需要 146 个单元测试来验证 property\collection 名称。

我的问题是我需要一个测试来测试测试:)

有没有办法验证实体计数 == 测试方法计数（其中名称以 X 开头，因为类中有很多方法）

【问题讨论】：

你应该关注unit test coverage而不是测试的数量。
所以您想确保每个实体都有一个测试？一个好的测试运行者会告诉你在一个测试集中有多少测试——这不能满足需求吗？
为什么需要测试每个属性/集合的名称？这听起来像是一个非常脆弱的测试，与实施过于紧密。
@Branislav ...是的...它很烂:) 但问题是当您从模型中删除实体并重新添加它时，实体不会保持其状态。所以我们需要一种方法来检查以确保它返回时的命名空间和大小写与原来相同。 WebApps 会很好，它们不会编译......但是具有数百个随机页面的旧网站，我们无法对它们进行全部测试，并且该网站一开始就无法构建。是的，我想我可以将这些提取到他们自己的班级然后看看。
对我来说问题出在有 146 个测试、142 个实体......丢失了

标签： c# unit-testing testing

【解决方案1】：

如果我理解您希望验证您已为 ORM 解决方案中的每个实体编写测试的问题。具体来说，您假设如果有 146 个实体，您应该有 146 个相应的测试。实际上，您想要断言您已经编写了正确数量的测试。

最明显的解决方案是在测试程序集上使用反射并提取您正在寻找的测试。您可以在这里做很多简单的事情，包括构建实体哈希集和使用命名约定或您定义的自定义属性识别测试夹具。

但是，在遇到类似问题之前，也许更优雅的解决方案是使用一些自定义测试框架代码，这些代码使用元数据和反射来测试实体。同样的“如何测试测试”问题也出现在这里，但可以通过编写一些测试来证明长期形式测试和自定义测试框架实现相同的结果来缓解。如果您可以证明您的自动化是可靠的，那么您对测试的维护问题就不再是问题了。另一个优点是，如果测试频繁运行，您可以随机化测试数据并发现实体中的意外问题。

【讨论】：