使用自动测试数据进行昂贵的维护

Question

在我的公司,我们在Java Web应用程序中使用JUnit进行了越来越多的集成测试.每个测试都使用一些特定的外部XML文件,用测试所需的数据填充数据库.问题是:

1. 当模型发生变化时,我们需要很长时间来纠正所有XML文件(我们有数百个XML文件,其中很多都是冗余的).
2. 手动创建XML文件的复杂性阻碍了程序员探索不同的场景.
3. 我们在测试数据和测试之间没有链接(例如,在测试时我不知道XML插入的用户的'名称').我们可以硬编码我们需要的信息,但它也会增加维护时间,以保持XML和硬编码数据的同步.

面对这个问题,我开始考虑使用自己的系统CRUD为每个测试生成测试数据.在每次测试开始时,我会运行一些方法来保存测试所需的数据.在我看来,它将解决以下所有3个问题:

1. 对模型的更改无论如何都需要更改CRUD,因此不再需要更正测试数据.
2. 构建测试数据会更容易,因为我们不会担心手动匹配实体的id和外键.
3. 我会在IDE中保证同步的所有重要数据.

但是,对我来说,缺乏开始这种方法的经验和知识.问题是:这个解决方案有效吗？这种方法会导致其他问题吗？我可以在文献中找到这种方法吗？对列出的问题有更好的解决方案吗？

Answer 1

提高可维护性的关键是保持DRY。测试数据设置不应该是多余的，如果您的测试技术没有提供有效的重用手段，那么您就使用了错误的技术。

为测试数据设置编写 Java 代码为您提供了熟悉且良好的工具，可以提高跨测试的代码重用。它还提供了比 XML 更好的重构支持，并使测试数据和测试代码之间的链接变得明确，因为它们位于相同的源文件中（甚至是相同的方法！）。然而，它确实需要由程序员（而不是不懂 Java 的业务分析师、经理或测试人员）编写和维护测试。

因此，如果测试数据主要由程序员编写和维护，我会通过实际应用程序的 CRUD 层（甚至是成熟的域层）在 Java 中进行操作。然而，如果大多数测试数据源自某些数据导出，或者由非程序员的人编写，则纯粹的数据驱动方法可能更适合。也可以结合这些方法（即为每个实体选择最合适的策略）。

个人经验：我们的团队曾经使用 DBUnit 进行集成测试，但现在转而使用我们的真实数据访问层将测试数据设置为测试代码的一部分。这样做，我们的测试变得更能揭示意图并且更容易维护。测试工作量减少了，但测试覆盖率提高了，并且用更少的刺激编写了更多的测试。这是可能的，因为测试完全由开发人员编写和维护。