最近我写了一套依赖大量测试数据的单元测试。这个集合包含十二个元素，虽然这听起来并不像在测试中使用时那么多。
每个元素都需要使用唯一值设置多个属性。问题是使用这种方法是创建这组数据的工厂方法是巨大的。
关于此问题的最佳做法是什么？我的应用程序实际上通过文件读取数据但是对于测试我使用了来自内存存储器的模拟数据。
有什么建议吗？
答案 0 :(得分：8)
您的测试结果如何？
您确定要编写单元测试而不是代码的多个组件的更高级别测试吗？纯单元测试应该只调用一个方法，并且该方法有望对其他方法进行有限的调用（可能通过mocking）。
通过关注可能的最小单位，您可以编写代码来测试特定的边缘情况。然而，如果您在更高级别进行测试，则通常需要编写所有类型的边缘情况排列。一旦覆盖了所有较小的单元，就可以编写一些更高级别的集成测试，以确保正确组装所有这些单元。
例如，如果我有一个应用程序读取股票报价的CSV文件并平均给定日期的所有报价，我会写几个测试：
如果我对您的单元测试做出假设，我表示道歉，但根据我的经验，我发现人们所谓的单元测试通常不是真正的单元测试而是集成测试（或者您喜欢称之为的任何东西，例如功能测试等）。我个人非常内疚地编写太宽泛的测试，每次我现在编写测试时，我都要强迫自己记住每次测试一个单元。
答案 1 :(得分：0)
难道不能以编程方式从实际生产数据的受控数据集中创建项目子集吗？这就是我们的工作，如果数据模型发生了变化，我们会在测试中使用它之前将一些脚本更新为真实数据。
答案 2 :(得分：0)
方法很大。管理并使测试套件变得庞大，这太可怕了。
我有一个单独的程序来生成测试数据。生成的测试数据存储在磁盘上，受版本控制，并可在单元测试中使用/使用。此程序的大小/复杂性（例如，它有自己的UI）不会影响单元测试本身的大小/复杂性。
这是“生成数据很复杂”的解决方案（但我不建议用它来生成千兆字节的测试数据，这可能会在运行中更好地生成）。
另外，我这样做是为了进行集成测试（而非单元测试）。
答案 3 :(得分：0)
我想推荐Gerard Meszaros的xUnit Test Patterns: Refactoring Test Code。
此案例类似于General Fixture smell：
可能的解决方案 我们需要移动到Minimal Fixture来解决这个问题。最好通过每次测试使用Fresh Fixture来完成。如果我们必须使用共享夹具，我们应该考虑应用Make Resource Unique重构来为每个测试创建一个虚拟数据库沙箱。 （请注意，切换到不可变共享夹具（请参阅共享夹具）并未完全解决此问题的核心，因为它无法帮助我们确定每个测试需要夹具的哪些部分;只有经过修改的部件才能识别出来！）
答案 4 :(得分：0)
此测试数据集支持多少测试方案？
理想情况下，应该分解您的测试数据，以便每个方案都有单独的测试数据集。否则你的测试场景间接依赖于彼此，无论如何这都是邪恶的。
换句话说，让多个场景共享相同的数据集会导致修改一个场景的共享数据集无意中使数据与另一个场景不兼容的可能性。
答案 5 :(得分：0)
如果您的问题与生成更大的测试数据集有关，您可以使用像NBuilder这样的库。我们使用NBuilder生成大量测试数据。它提供了非常流畅的界面，非常易于使用。您可以找到相同here的小型演示。