单元测试代码生成

Question

我们有一个为期两年的项目，但其架构设计很差，而不是单元测试。

该软件运行良好，但我们正处于重构一些核心模块的阶段。

预算也是有限的，所以我们不能雇佣足够数量的开发人员来编写单元测试。

通过一些方法自动生成单元测试代码以涵盖(例如)集成场景是否也是一种可行的策略？一个假设是，考虑到系统现在运行良好，并且它的输出可以转换为XML数据进行单元测试？

这种方法使我们有可能快速开始重构现有代码，并在某些核心功能因这些更改而中断时立即接收反馈。

Answer 1

好吧，我用我写的层次树数据结构做了这件事。数据结构分析输入数据集，并基于该数据集及其定义的数据关系创建树。

我使用各种输入数据集创建了树，这些数据集足以涵盖各种情况(大约有60个测试)，将每棵树序列化为XML，当我满意每个树生成的XML输出时，使用这些序列化字符串作为单元测试的预期结果。

它成功了吗？是的，很好，事实上，这只花了一小部分时间

有缺点吗？

1. 测试相当脆弱(当对代码进行任何更改时，测试就会中断)。
2. 并不总是清楚在每个测试中到底测试了什么，因为没有将测试映射到单个需求。
3. 如果一个测试失败了，其他几个测试也会崩溃。
4. 诊断失败的测试需要获取预期的和实际的测试结果，将它们粘贴到文本编辑器中，并运行一个diff来查看发生了什么变化。

Answer 2

如何生成匹配的输入和输出？一方面，您有被测试代码产生的输出。另一方面，你有--什么？输出的不同实现相同的算法？如果有一个琐碎但缓慢的算法可以用来测试更复杂的更快的算法，这可能是有意义的。还是你打算盯着预期的输出，只是测试不想要的变化？在这种情况下，很容易接受不正确的输出。

在我的经验中，生成的测试和投入它们的劳动一样有价值。

Answer 3

我从没听说过单元测试生成。如果可能的话，每个人都会使用它。如果有什么东西存在，我相信它不能保证您的代码得到了正确的覆盖。

我认为这种遗留代码的最佳方法是为任何新特性和任何新的重构编写测试。第一步对于应用程序的稳定性将是相当危险的，但是您很快就会拥有一组相对较大的测试。

这种方式可能非常有效，因为在第一次，您将面对代码中最糟糕的部分(为了进行必要的重构)和核心特性(因为它们将受到任何进化的影响)。这样，您的应用程序中最重要的部分将很快被涵盖。

您将无法实现完整的覆盖，但是如果您不需要回到旧的代码段，这可能意味着该代码与其他代码的粒度比较弱。