不起眼的自动化测试

写代码的时候，有一个不太起眼、有时感觉很无聊的工作，叫测试。

能不能不做？好像也不行，毕竟谁也不能保证不出bug，一写就顺，一跑就通，那可能不是人，是神。（以后可能是ai）

为什么说很无聊，因为总是在重复，尤其是出bug的时候。

所以慢慢的，自动化测试就出现了。

何为自动化测试，这个程序员最懂了，自动化，就是用程序代替人工，有个程序帮你搞定整个流程，代码写完了，跑一下，哪哪有问题都给你定位出来，直接改就行。

听着很完美，但有个问题，测试程序哪里来？我写完业务代码，能自动给我一个测试程序吗？

还别说，现在各种编辑器加上了ai，真就有了这个条件。当然，现在的ai给你生成了也不一定就完美，需要加以确认。

但是，这已经是大大降低自动化测试的门槛了。过去程序员们还得边写业务代码，边写测试代码，难受得很。

这也是今天聊自动化测试的原因，随着ai的发展，自动化测试会越来越普及，但前提是你得知道有这个东西，得会用。

自动化测试分了很多种，什么单元测试、集成测试、端到端测试、性能测试等等。今天来聊最基本也是最核心的一个，单元测试。

什么是单元测试？单元，可大可小，但通常意义上，指的是一个单独函数，或者一个单独的类。

一个函数有什么好测试的？换个角度想，只要每个函数都能正常运行，那你的系统大概率就没什么问题了。

对系统来说，函数通常产生几种结果：返回预期的值，或者改变了某个对象的状态或者行为。

要怎么测呢？或者说，测试程序怎么写呢？

业界有很多种组织模式，比较常见的是两种，叫Arrange-Act-Assert（AAA）、Given-When-Then（GWT）。

Arrange是准备，就是把测试条件准备好。由于是单元测试，为了得到快速的反馈，通常不会有任何外部依赖。所以准备环境的时候，通常就是创建好测试对象，如果有需要外部依赖的数据，就采用mock的方式直接创建一份。

Act比较好理解，就是执行操作，需要测试什么函数，就调用什么函数。

Assert是断言、做验证。主要验证返回值，或者验证对象的状态是否符合预期。

GWT也是类似的，但是GWT更侧重业务场景，测试业务的行为，表达上更偏自然语言，常常用于接口测试场景。而AAA则更偏向代码自身的测试。

简单来说，就是再写一个函数或者类，执行上面的几个流程，输出测试结果。

用上各种测试框架+ai，so easy。

那什么时候执行这个测试程序呢？通常有两个阶段。

一个是本地开发阶段，写完代码或者改完代码，就跑一下，结果ok了，再提交代码。

另一个是持续集成阶段，也叫ci阶段。大型的公司通常会有标准的ci接入方式，只需要将测试配置好，集成时会自动运行，这时候通常是所有单元测试都跑一遍。

做这么多，有什么好处吗？可能bug被拦住了，程序员修修改改放心多了，但好像也没带来多大收益。而且有时候频繁修改代码功能，还得跟着修改测试代码，成本很高。

也许等程序员bug修怕了，都不太敢动代码时，就是那个引入自动化测试的timing了。（手动doge）