TDD With Unity LLM Agent

TDD测试驱动开发作为开发模式我以前在游戏开发中几乎没用过。我以前用的基本就是敏捷开发、原型模式这些适合需要快速迭代的情况。但随着技术发展LLMAgent 能力与日俱增TDD 这样以往不太适合游戏开发的模式现在却成为了最佳选择。为什么是 TDD如果是传统的游戏开发倒也确实不必要 TDD。TDD 最大的好处就是给工程开发提供确定性每一次修改、重构都能有一个可靠指标保证没有错误不然无法通过测试用例。但对于游戏开发一大悲剧就是需求本身都不明确TDD 的基础都难以保证测试用例自己的生命周期都如风中残烛他所提供的可靠性自然无人在意。相信大家在游戏开发中经常遇到如此情况我开发了一个功能过几天就不要或者大改。那既然如此我为他写一个甚至多个测试用例的意义在哪里呢这就是 TDD 的最大痛点设计测试用例的时间成本在快速功能变更中难以承受。那为什么现在又需要把 TDD 捡回来而不继续使用传统开发模式呢因为在 LLMAgent 的开发模式下时间成本被大幅压缩平时十多个人两三个月的工作现在一个人开几个 Agent 只需要不到 1 天就能完成。经过我自己的一些实际体验使用 AI Agent 的人月效率大约是普通程序员的 100 倍左右。也就是说普通程序员要 3 个月的工作让 AI 来做只需要 1 天。此时决定开发进度的原因也彻底改变了以前是人的开发速度不够快现在是人的验收速度不够快。所以在当前情况下TDD 的优势体现出来了TDD 能够提前约定验收项目从而让 AI 能满功率开发不被人类的工作进度卡住。除此之外更重要的一点就是 TDD 是一个收敛的开发模型当满足所有测试用例后开发自然也就停止了。但不论是迭代、敏捷、原型显然都是发散的开发模型需求越做越多系统越来越复杂直到最后完全无法维护。但说实话上述问题 TDD 也无法很好解决并不是用了 TDD 开发地狱的问题就会消失了。要解决着这个问题还是要靠人的能力提升团队如果自己都不知道要做什么那也不是开发模型能解决的问题。但是在 AI 时代如果采用传统的开发模式是会放大这些弊端AI Agent 在没有良好约束的情况犹如脱缰的野马一路狂奔等开发人员回过味来已经来不及了。新的技术带来新的工作方式在 AI 时代最快的开发方式就是能让 AI 最快、最有效迭代的开发方式。此时测试驱动开发成了最佳选择。如何在 Unity 中使用 TDD在 Unity 中使用 TDD 有一个最为关键的问题如何让代码脱离 C# 独立运行。由于 Unity 大量代码依赖其底层导致无法直接在 Unity 外运行代码即便无编译错误。而对于大模型开发这一点就非常恼火因为不能运行自然就无法正常跑测试用例除非我们在每一个智能体开发设备上都放一个 Unity 编辑器。想要脱离 Unity 编辑器跑 Unity 代码目前来看是不现实的现阶段也没有匹配的解决方案。因此这里我建议进行如下操作About Unity Test Framework | Test Framework | 1.4.6https://docs.unity3d.com/Packages/com.unity.test-framework1.4/manual/index.html在 Unity 内使用 Unity 自己的测试框架 Unity Test Framework 来编写测试用例。注意这里编写测试用例时建议严格区分纯逻辑可脱离 Unity 运行且无 Unity 依赖部分和依赖 Unity 的部分以便于部分测试能够脱离 Unity 运行。在外部构建测试工程用来编译项目代码需引用 Unity 的 dll 和第三方插件的 dll以及有一个能连上 Unity 编辑器真跑测试的脚本。分两个轨道A静态轨只进行静态编译测试不跑逻辑用于大模型常规开发使用大模型可以自行判断逻辑问题。B动态轨可以用启动、运行的测试用例由持有 Unity 编辑器的智能体运行并给出基线报告。在目前无法在外部 .Net 环境直接跑 Unity 代码时这就是一个权宜之计能够让当前项目直接用 Unity 就能够跑起来。当然上述都可以自动化进行可以让 AI 写个 Unity 的命令行脚本让 AI 能自动启动 Unity 测试框架进行测试、出基线报告基于 TDD 进行游戏开发首先需要在 Unity 里建立不同的程序集例如代码的框架层、业务层然后测试需要单独一个特殊的程序集可以让 Unity 自动创建一个Window→General→Test Runner 打开面板可以让 Unity 自动创建一个程序集。创建之后还需要我们手动引用需要的业务代码程序集否则无法使用我们自己的代码创建好示例如右图所示。如果有报编译错误需要引用的程序集也可以自行引用即可。之后就可以自行编写测试代码了例如public class Crc32Tests { [Test] public void Compute_EmptyData_ReturnsZero() { uint result Crc32.Compute(new byte[0]); Assert.AreEqual(0u, result); } }之后就可以点击 RunAll 运行全部测试用例。当然测试用例都不可能全部人工写人工只会做一些典型使用场景的测试用例重要的部分其余的边界、异常值则由 AI 代劳了。一般来讲按照 TDD 的标准流程应该是在业务开始前就写测试用例然后再实现功能总之TDD 的意义在于能确保当前新的的功能没有引起新的逻辑问题回归同时我们将功能的完成情况做成了一个可量化的指标测试用例通过情况。在后续的开发尤其是使用 AI 开发时我们能随时查看基线情况来给项目以安全保证。