我正在使用一个遗留应用程序，该应用程序使用了一些众所周知/可怕的数据建模模式，称为 EAV。这使得选择在 DAL 的单元测试期间使用的数据生成策略变得困难。为什么？因为，除了表之间的正常 Fk/Pk 约束(我们在可能的情况下使用)之外，还有其他关系/约束，只有应用层知道并强制执行。
根据这个article ，最容易编写和维护的数据测试是那些依赖于外部定义和静态数据集的测试。但是，似乎尝试创建一个数据集来合并已经“手动”在我的应用程序层中建模的关系，这将是一个 DRY 违规并且也是一个主要的 PITA 引导。另一方面，使用我的应用程序层生成测试数据感觉更令人反感，因为这违反了单元测试的主要指令(隔离)，因为应用程序层中的回归会导致我的 DAL 层抛出虚假故障。
出于这个原因，我倾向于静态数据集选项，除非其他必须处理 EAV 模型单元测试的人可以加入替代方案。
非常感谢。
最佳答案
如果 DAL 不负责在数据存储中执行某些应用程序规则，则无需确保测试数据符合那些更高级别的规则。单元测试只需要验证 DAL 执行它负责的规则——大概是在数据库约束、数据类型等范围内。数据只需要符合 DAL 的先决条件本身构成一个有效的测试用例。更高级别的规则将在应用程序层的单元测试中进行检查，其中 DAL 将被 stub 或模拟出来。在这些假设下，静态数据集或使用普通代码生成的数据集可能足以进行 DAL 测试。
很可能是因为应用程序的“遗留”性质使得很难甚至不可能分别对应用程序和 DAL 层进行单元测试。实际上，这两层共同构成一个(如果复杂的话)“单元”。在这种情况下，作为权宜之计，使用应用层生成测试数据是可以接受的(或者“可以容忍”是正确的词)。实际上，这样的一代将构成企业集团“单位”的更多测试案例。由于应用层回归导致的 DAL 故障应该作为一个、另一个或两个层中的候选错误进行调查。从长远来看，花任何时间尝试将这两层分离成单独的单元都可能会带来返回。
关于database - 为复杂数据库 (EAV) 生成单元测试数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6991033/