管人管项目 - 要写测试 ¶

我们需要质量好坏的反馈 ¶

写完代码，跑起来会怎样？——自己运行一下呗

可是稳定性如何？——自己试多几遍呗

那有没有影响其它模块？——这可不好说了

我们就有这样的需求，因为并不是写完一个代码后，只要在一个地方测试就能保障软件整体是没问题的

我们需要多方面、从不同功能业务或不同的参数值角度来测试才能确认新写的这块代码是否可靠

可是手动测试在软件进度去到40%以上时往往会变得不足够，重复的手动测试浪费时间比较长

钱安川提到单元测试的价值并不是因为它叫单元测试，而是它能更快地向你反馈代码的情况，更快，意味着省时

以没有时间为理由而不写测试是不正确的价值观从我明白测试的价值后一直这么认为，其实只要一个程序员掌握测试技术后，能熟练地部署测试脚手架、快速地创建测试用例和编写断言时，写测试代码已经不费什么时间，这个完全可以通过练习来掌握起来

最基本的做法就是用TDD编码方式，这里不讲TDD是什么，自己查，我只想说：那么有空写一下代码，再切换窗口点一下应用确认效果，不如把时间花在写测试代码上，写好后跑一下命令就有结果，下次跑这个测试还不用再写代码了呢

某Web项目要开发某数据增、删、改、查功能

我先使用一个写好的bat脚本输入新的测试用例名称然后创建了测试用例

以增加接口为例，先在项目里创建了增加逻辑的类和方法，按照我的设想写好了初步的代码，此时未进行调试

然后在测试用例中添加testAdd方法，new这个逻辑类，传入测试参数初始化，调用add方法，断言add的返回结果为一个map

然后运行bat脚本，输入测试用例的名称运行这个用例

运行过程中报了一下错，这个报错我发现是逻辑类里的代码有问题，于是去调整，反复几次，终于没有了报错，并返回了map成功通过断言

我再完善一下测试用例，加入2次不正确的参数调用，断言会抛出异常，其中有1次报错，说明业务代码对这些不正确的参数处理不严谨

优化对不正确参数的检测处理后，再跑一下就正确了，现在确保了业务逻辑相关的类是能基本正常运行的

开始编写控制器代码，和单元测试的流程差不多，先new出业务逻辑类，将http请求参数传进去初始化，执行add方法并返回map，控制器将map序列化成json返回给请求端

在框架的URL规则中添加这个控制器方法的白名单开放访问，再使用Postman之类的HTTP请求模拟器输入网址填写参数发起请求

查看返回的结果，和单元测试的一样，这是经常的事，因为单元测试已经帮我确保了业务逻辑是正确的，我的http测试工作量会很少

如果返回结果不符合预期，先确认这种HTTP参数在单元测试中是否模拟过，如果未模拟就完善单元测试，如果模拟过就基本可以确定是控制器向业务逻辑传值这个环节出了问题，排查的范围已经变得很小

经过简单的修改就正常了，更多的测试是在单元测试上解决了，并且很快

关于这块，可以参考的单元测试代码是这里，顺便贴上控制器的调用代码

也许跟平时的功能开发时间比起来差不了多少，在特定情况下，是明显有提升速度，但也有特定情况下会发觉鼓捣这些还不如写一下，手动测来得快

但是当这块业务逻辑被别的东西依赖时就不是这么算账的了

以后改了别的地方后，又要测这边的，你再手动测，时间啊时间！

所以这些已经写好的测试代码，在以后为别的新模块写好代码后，只要一个命令跑起来，等上几秒到十秒就有结果了，都知道另一块会不会被影响了

不要太自信啊骚年你知道现在有多少大牛们都提倡要写测试吗，有多少略有档次的项目、公司在招聘程序员时要求至少能写单元测试？

本文讲的测试并不特指单元测试，其实还指其它比如API测试、功能测试、验收测试，只是单元测试最容易下手所以就拿它来做案例，认真体验过好处的人都知道这绝对是最佳的测试学习切入方式

测试也不只是测试工程师的事，起码单元测试这块，最适合由开发工程师自己写