cpp单元测试工具 推荐_挖掘单元测试用于代码推荐

1 引用

Mohammad Ghafari and Carlo Ghezzi and Andrea Mocci and Giordano Tamburrelli. Mining unit tests for code recommendation. In Proceedings of the 22nd International Conference on Program Comprehension, 2014, 142-145.

2 摘要

开发者花费大量时间来理解和学习需要集成到项目中的 API 的正确用法。然而，学习如何有效使用 API 既复杂又耗时。代码推荐系统在这方面起着至关重要的作用，可以在开发者编写代码时向他们提供相关代码示例。本文提出了一种新的代码推荐方法，该方法通过挖掘单元测试的方式自动化获得代码示例。本文讨论了这一思想的理论和实践意义。这一讨论引出了一系列在我们在研究议程中组织的有趣的研究挑战。

3 技术介绍

开发人员通过使用现成的组件和框架提供的功能来应对现代软件系统的复杂性并加快开发过程。但是，有效地集成外部第三方库需要对应用程序编程接口(API)有广泛的了解，并且需要对所需的交互协议有详细的认知，然而这个过程既困难又耗时。此外，现实世界中的软件库和框架可能没有详细的说明文档，如果存在文档也可能包含错误或过时的内容。为了找到或生成推荐的示例代码，现有方法通常使用外部资源，例如现有项目的源代码和在线可用的代码片段。尽管它们假定此类信息源是可用的，但实际上，这些源可能是不可访问的或受限制的。即使可用，这些信息来源也可能是不可信的，甚至包含过时且质量低下的内容。这些问题阻碍了现有代码推荐解决方案在许多实际情况下的应用。

本文提出了一种基于单元测试的新颖且通用的代码推荐方法。我们假定存在一组给定 API 的单元测试用例，并且可以通过挖掘它们内在信息的方式，以合成适用 API 的推荐代码示例。这个想法背后的基本原理是，我们认为单元测试用例可以代表独立、一致且可信赖的信息源，从中可以合成有意义、有用的代码示例，并推荐给开发人员使用。我们的方法具体包含了三个步骤：(i)识别单元测试和被测试单元之间的关联关系，(ii)从测试中合成代码示例；(iii)基于合成代码示例构建一个推荐系统。

3.1 识别单元测试与被测代码之间的关联关系

研究的第一步就是识别测试与被测单元之间的联系。我们的方法需要确定每个单元测试的目的。这不是一件容易的事，因为测试文件可能包含许多具有不同角色的依赖项，需要对其进行正确分类。实际仅有一部分单元测试用例的子集是真实有用的。此外，测试用例通常依赖只在测试准备步骤中用到的类，其中某些类仅在测试环境中使用，例如 Mock 对象。我们的方法基于这些依赖关系对测试进行分类，在给定特定的开发上下文的情况下，在推荐时可以给出恰当的使用示例。

现有的方法在类的粒度级别而不是方法级别来识别测试代码元素。我们设计了一种简单的方法，该方法利用测试的结构统一性来识别测试类中的测试方法。为了找到方法级别的代码示例，我们考虑位于断言语句之前的代码元素。更准确地说，我们寻找最后一个方法调用，该方法调用随后会影响断言。为此，我们利用 Eclipse JDT 解析器和类型检查器来开发一个插件，该插件分析测试代码的抽象语法树(AST)，并在每个测试方法中的断言之前检查包含方法调用的表达式。然后，从最接近每个断言的调用开始，我们使用动态切片方法来查找影响断言结果的调用语句。

3.2 合成测试代码示例

在这一步中，我们的方法需要从上一步中确定的测试方法中合成代码示例。上一步得到的测试的结构中包括不能直接作为建议的部分，如断言和 Mock 对象，因此现有挖掘方法不能直接应用于测试代码。我需要进行下面几步的处理。

首先，考虑测试的准备部分和依赖部分。测试准备是测试代码的重要组成部分，它满足执行测试所需的前提条件。构造测试准备的通常做法是将其封装在一个辅助方法中，该方法可以由一组需要相同测试准备的测试方法调用组成。尽管这减少了代码重复和维护成本，但我们可能需要将准备代码融入我们的测试方法中，以提供更具可读性和独立性的示例。类似地，可能需要将其他依赖项(例如抽象初始化和 Mock 对象)替换为其相应的程序实体。解决这种依赖性并非易事，因为它可能不存在于测试代码中。

其次，我们的方法可能需要删除与用法示例无关的语句。为了简化开发人员的工作，我们需要生成相对简洁的用法示例。挖掘的示例必须在提交给用户之前进行处理，以消除不必要的声明(如断言)。

另外，有必要区分展示典型用法的单元测试用例和用于检查异常行为的测试用例。前一种情况包含用法示例，而后一种情况则告诉用户不应执行的操作。此外，一种测试方法可能包含多个测试场景，这可能会导致开发人员误解测试的目的，从而导致误解该测试的代码示例。

3.3 代码推荐

如果没有推荐系统，则要求开发人员手动浏览一组使用示例并将其应用到自己的需求中。但是可能只有几个测试用例适用于开发人员正在进行的任务。代码推荐系统通过将开发上下文视为查询来查找相关代码示例，以找到与程序员正在编辑的上下文相似的相关示例。例如，上下文可以由开发人员当前编辑的方法中的变量类型组成。

通过上面两个步骤得到的代码示例集后，我们就可以构建自己的推荐系统。像许多其他推荐系统一样，我们提出的方法需要根据特定使用场景的代表性对使用示例进行排名。实际上，测试套件中可能有许多类似的测试场景。在这种情况下，开发人员可能会找到相关的测试用例，但不一定是最好的测试。为了给开发人员提供最具代表性的测试用例，必须丢弃多余或相似的测试用例。最后，我们应该适当的修改测试用例以使其与开发人员定义的现有程序内容相匹配。

3.4 评估

为了评估和验证我们的方法，我们计划进行一个分为两个阶段的评估研究，其中将要求两组开发人员实现一些具有不同文档质量的 API 的几种常见和复杂的使用场景。我们通过比较执行任务所花费的时间及其正确性来评估每个组中开发人员的效率，以此来衡量我们方法的有效性。为了确保研究的有效性，参与者不应该在使用之前接触和了解相关 API。

在研究的第一阶段，第一个小组将仅使用我们的工具，而另一个小组则可以手动访问测试套件以及 API 文档。在此阶段禁止上网，以避免使用可能会使实验结果失真的补充资源。为了研究我们的方法相比于现有的工具可以多大程度的帮助开发人员完成开发任务，我们进行了研究的第二阶段，第一个小组仅使用我们的工具，第二小组不再受到限制，可以任意的访问互联网资源。

4 本文主要贡献

代码推荐系统可以在代码编写时向开发人员提供相关示例，从而帮助开发人员使用复杂的 API。现有的代码推荐方法大多采用挖掘网络上代码信息生成代码示例进行推荐。然而这些来源可能是无法访问、受限的、不可信的、质量低劣或者过时的内容。 在本文中，作者描述了一种新的代码推荐方法，其中通过挖掘和处理要推荐的 API 的单元测试用例来获代码示例。作者给出了具体的实现方法以及相对应的评估实验方法。

致谢

感谢国家重点研发计划课题：基于协同编程现场的智能实时质量提升方法与技术(2018YFB1003901)和国家自然科学基金项目：基于可理解信息融合的人机协同移动应用测试研究(61802171)支持！

本文由南京大学软件学院 2018 级硕士生门铎翻译转述。