写在前面

这次我也试着写个短文吧，我发现之前我写的文章都喜欢长篇大论但啥也没讲凑字数。 当然，写这篇文章的契机，是最近写自己的mlnm项目的时候，在单元测试这边纠结了一阵子，最后通过实验得出了自己的结论。

AI与单元测试

我最初接触单元测试的契机，大概是用AI编程的时候，接触到了一个基于测试开发的编程思想，也就是所谓的测试驱动开发，这个开发思想就是倡导先写单元测试，再写软件，然后AI正好是用来写单元测试的最佳工具。

所以我当时就用AI先写单元测试，然后再用AI写具体的代码，完成了第一版的NNW。

不过因为第一版完成效果实在不行，觉得架构上也过于复杂，而且AI写的代码维护起来难度很大，就连单元测试也很难维护和读懂，因为我发现AI似乎并不懂得精简单元测试，非要写得非常细，导致很难阅读，所以我后来也重新写了个自己版本的单元测试。

因为NNW本身是写起来确定性就很高的程序，所以单元测试实际上也很容易写，并不需要考虑太多东西。

单元测试与游戏开发

实际上，我个人感觉，游戏开发一直都是很难用到单元测试的场景，因为游戏开发的测试似乎总体更依赖直接进入游戏查看实际的游戏运行效果。

不过，我发现如果是部分游戏引擎的开发，涉及到比较确定性的引擎层基础功能这类，特别是写项目写到自己无法把握全貌的时候，单元测试也会相当有帮助。

在游戏开发中，单元测试从定位上，感觉更适合用来调试游戏的数据层功能这类输入输出确定性完全固定的，或者测试部分编译、脚本层能否通过这类确定性用途。

毕竟，也很难想象你用单元测试调试图形层和操作，那样就太辛苦了……

单元测试的作用

我实际写单元测试的时候，也很容易遇到一个问题，就是总觉得没什么可以写的，想不清楚该写什么。

虽然单元测试是很强大的工具，但如果想不清楚应该写什么的话，好像也没什么意义了。

有时候也会在猜想，我写一些明明就觉得输出不用猜都能很清楚的方法的单元测试，会不会有点太繁琐了。

不过最后我发现，实际上很多时候如果改动了接口，那么哪怕是输出很清楚的方法的单元测试，对于调试接口改动的影响范围，也会非常有帮助。

此外，我发现单元测试最好的写法，其实并不是一开始就把所有的点全部想清楚写出来，其实并不需要一开始费尽心思写完所有的部分。

最省力的方式，其实还是先调试项目，在调试的过程中如果遇到觉得可能会出问题的点，再用单元测试做个笔记一样的东西。

总结，单元测试的作用，实质上更像是，开发过程中看到可能会出问题的点，把这些点整理起来，避免下次改动再出问题这个情况。