最近，我们在围绕 AutoDev 开源插件，构建完整的端到端开源辅助编程方案。即：

• 结合 IDE 插件微调开放二进制大语言模型（所谓 “开源”模型）。
• 构建对应开放对应的模型与数据集
• 构建针对于微调的开源数据工程：Unit Eval 。

简单来说，就是依旧在 Unit Eval 开源项目中设计的：“用调评”一体化（即 AI 工具-模型微调-模型评测一体化），以构建更贴合于不同组织现状的编码方案。

如何让 AI 写好测试？

在大部分编码场景中，AI 辅助单元测试的效果是相对最好的。但是这也并不简单，其中的难点在于如何构建好的上下文。

什么是好的 AI 测试上下文？

作为一个经常刷测试覆盖率，以及在 ArchGuard 中构建了测试坏味道分析检查工具的工程师，我大抵可以算得上是一个经验老道的单元测试专家。

在 AI 生成的背景之下，我们预期一个好的测试上下文，它应该包括：

• 类的构造信息（constructor）。
• 接口、函数的输入和输出。以使得测试能构建出正确的输入和输出
• 测试框架的相关信息。诸如于采用的是 JUnit 4 还是 JUnit 5，使用的是哪个 Mock 框架
• 测试代码规范。诸如于命名方式等

如下是一个经典的，用于练习的测试示例：

// ....
import org.junit.jupiter.api.Test;

@SpringBootTest
@AutoConfigureMockMvc
class BlogControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private BlogRepository blogRepository;

    @Test
    public void should_return_correct_blog_information_when_post_item() throws Exception {
                BlogPost mockBlog = new BlogPost("Test Title", "Test Content", "Test Author");
            ....
        }
}

在这个普通的测试里，如果缺乏上述的一系列信息，那么会导致一些有意思的错误：

• 使用 JUnit 4 来编码 JUnit 5 的测试
• 使用错误的 Mock 框架
• 生成的 BlogPost 构建函数是错误的
• 直接调用 private 方法，而非绕过其它的方式
• 测试函数的命名是不规范的，不遵循内部的开发规范。

其它的可能还有诸如于缺少测试断言等其它的测试坏味道，所以上述的信息就变得非常有必要。基于我们积累下来的单元测试与 IDE 插件经验，便需要考虑一体化的工程思路。

为什么基于开源模型微调？

依照我们设计的 “一大一中一微” 的三模型体系，为了解决测试代码的生成问题，我们采用了 DeepSeek 6.7B 模型作为代码生成模型基础模型，以满足代码补全、测试生成两个高频高响应速度的需求。而为了在 AutoDev 中为了提升生成结果的准确度，使用静态代码分析生成更精准的上下文。其中包含了：

• 技术栈上下文
• 测试技术栈上下文
• 代码块（类、函数）的输入和输出信息

如下是在 AutoDev 中精简化后的 Prompt 示例：

Write unit test for following code.

${context.testFramework}
${context.coreFramework}
${context.testSpec}

${context.related_model}

```${context.language}
${context.selection}
```

而在我们测试了一些开源模型之后，发现理解 prompt 以及上下文的能力是有限的，甚至可能无法理解，以至于生成不了测试代码。为此，我们就需要围绕于测试提示词的上下文，构造微调数据集。

“用调评”一体化：围绕于提示词的上下文工程

在 Unit Eval 中设计的三个核心原则：

• 统一提示词（Prompt）。统一工具-微调-评估底层的提示词。
• 代码质量管道（Pipeline）。诸如于代码复杂性、代码坏味道、测试坏味道、API 设计味道等。
• 可扩展的质量阈。自定义规则、自定义阈值、自定义质量类型等。

基于这三个原则，再融合我们的测试经验，Unit Eval 中便有了测试生成的数据工程能力。然而，这并非一件简单事情，在测试这个场景之下，我们可以再看看如何实现。

统一提示词：识别基础元素

在 AutoDev 中，会从 Project 中读取依赖管理工具中的 LibraryData 进而构建出对应的测试框架等信息。如下所示：

You are working on a project that uses Spring MVC,Spring WebFlux,JDBC to build RESTful APIs.
This project uses JUnit 5, you should import `org.junit.jupiter.api.Test` and use `@Test` annotation.
...

为了让模型能更好地理解对应的代码指令，在对应的测试数据集中，也需要构建对应的框架信息出来。在 Unit Eval 中会先调用 ArchGuard SCA 的分析工具，从中解析中依赖列表，进而生成的上下文信息。

代码质量管理：测试代码坏味道

而为了更好的结合的管理生成质量，我们还是需要控制一下数据集中的质量。因此，我们使用 ArchGuard Rule 来扫描测试代码，只放入生成比较好的测试。诸如于：

• 没有断言的测试
• 包含 Sleep 的测试 —— 说明测试写得并不好
• 过多调试打印信息的测试用例
• 过多 Assert 语句
• ……

当然了，根据不同的组织信息，我们还需要添加好更多的规划。

可扩展的质量阈：函数长度控制

在测试上，我们还需要进一步控制输入的测试的质量，诸如于测试代码函数的长度。当然了，现在 Unit Eval 控制的是整个类的长度，在未来将添加对于测试函数的控制。

一体化示例：AutoDev 与 Unit Eval

根据不同的微调场景，如基于内部代码库生成数据、让开源模型理解指令，所需要的数据集大小是不一样的。在这里的场景，是让开源模型能更好地理解 AutoDev 的指令。

结合规范的持续演进

结合上述的原则，我们构建了新的 Unit Eval 测试数据集：https://github.com/unit-mesh/unit-eval/releases/tag/v0.2.0 ，并进行了微调。

如下是，结合微调生成的测试用例示例：

@Test
public void testCreateBlog() {
    BlogPost blogDto = new BlogPost("title", "content", "author");
    when(blogRepository.save(blogDto)).thenReturn(blogDto);
    BlogPost blog = blogService.createBlog(blogDto);
    assertEquals("title", blog.getTitle());
    assertEquals("content", blog.getContent());
    assertEquals("author", blog.getAuthor());
}

虽然，生成的测试构建函数都是正确的，测试也是可运行的。但是，在这里，我们可以发现一个明显的问题：生成的函数名没有符合规范。

前面在 prompt 中要求的是类似于 should_return_correct_blog_information_when_post_item 方式命名的，这也会导致后续生成的测试方法都失去对应的准确性。因此，我们需要基于上述的原则，重新检查是否符合我们的命名规范，再进行微调。

保持提示词一致

在总结并编写这篇文章的时候，还发现了一些提示词不合理之处，并更正错误。诸如于：框架的提示词、命名方式等等。如下是更新完后的上下文信息：

- Test class should be named `snake_case`.
- You are working on a project that uses Spring Boot, Spring Boot Web
- This project uses JUnit, assertj, mockito, Spring Boot Test, Spring Test to test code.

当然了，还需要依旧测试的类型进一步演进。

总结

与编写一个可以用的 AI 辅助编码工具，如何持续演进整体的架构更有挑战。

PS：更详细可以参见：https://github.com/unit-mesh/unit-eval 项目的 README。