该文章同步发布於：我的部落格

到了铁人赛的最後一天，看了这麽多东西，我们可以来谈谈学这些测试的好处是什麽？

我可以想到五个原因，为什麽写测试是有帮助的。在这些原因下面还有更多的子原因，但我认为测试的任何好处都可以追朔到这五个的其中一个！

测试有助於防止 Bug

我个人发现，写测试的过程能够进入一种思维模式，透过思考想到一段程序码的所有可能性，包括我正在写的功能可能会出现错误的方式，这代表说，我写过测试的功能会比我没有写过测试的功能更不可能出现错误！

你可以把所有想到会有错误的可能性写成测试，当他错误的时候，就会知道到底是哪里有问题了！

测试有助於捕捉没想到的错误

我常常会在写一段新的程序码的时候觉得很糗，因为我发现我写的 Code 让原本的应用程序坏掉了，而且是我觉得不会弄坏的部分，但同时也让我变得谦虚，知道自己考虑的东西不够多，这时候自动测试就可以捕捉到这样意外的错误，会让你松一口气～

测试有助於改善设计模型

很多情况下，模组化和耦合程度低的程序码是很好被测试的，而且模组化和耦合程度低的程序码也很容易阅读和理解，所以当你用测试写出来的程序码，往往都会走向 好的设计，这也是另一种说法啦，鼓励写出容易理解的程序码～

测试有助於重构

基於刚刚第二点提到，测试也让重构变得有可能。我认为重构不仅仅是有帮助而已，而且还是必要的！当应用程序越长越大，如果不偶尔退後一步，观察任何重复且没意义的程序码，并进行重构，让程序码回到可以接受的 DRY，整个应用程序就会越来越失去凝聚力！

DRY = Don't Repeat Yourself 不要写出重复的程序码

能够帮助重构这件事情真的超级实用，有些专案你可能会因为没有测试，而不敢进行重构，尤其是耦合程度又超高的应用程序，真的觉得随便重构都会坏掉，所以这一点是我自己觉得最棒的优点！

测试可以像是文件一样阅读

当过了八个月後，我回头看一段程序码发现完全看不懂的时候，我可以去看看测试的叙述上面写了什麽，用意是什麽。

因为测试的部分只要写了易读的叙述，就能够很快的抓到重点，所以如果有写测试的话，并不需要加入太多的注释来帮助理解～

什麽是测试办不到的？

可以看到每个小标题都是以测试可以做些什麽开头的，尽管上面列出了测试的好处，但其实测试并不提供保证，测试不可能捕捉到每一个错误，测试不能证明没有错误，测试不能告诉你的 UX 体验是不是好的，或是你的产品有没有价值，但是，测试可以为了节省大量的时间、钱、劳力！

写专案时遇到的小事件

专案中有一段测试是使用 VCR 加上 WebMock 来测试简讯发送的程序码，但因为官方没有提供沙盒模式来让我们做测试，所以在推上 Github Action 自动测试的时候，每次都会在线上重新录制一次 VCR，这样每次一发 PR 修修改改後，可能就去了 5 封简讯。

於是我们在简讯测试的部分加上了 type，还是看看程序码好了～

scenario 'XXXX', type: 'sms' do
     .......
end

接着在自动化测试的指令加上：

bin/rspec --tag ~@type:sms

这边的 ~ 是 不要 的意思，就是在执行 RSpec 的时候不要测试 type:sms 的 example！

蛮实用的，可以试试看！

小结

终於结束了 30 天的铁人赛，没想到时间过那麽快，其实中间真的蛮容易想不到该写什麽，但到处看文章，找素材，就这样不知不觉得完赛了～

希望这 30 天的文章可以帮助到对於 RSpec 有兴趣的人，也能让你们在写测试的时候不要带着埋怨的心情，因为其实写测试的过程也是蛮有趣的，可以放入一些极端的条件去测试自己的程序码，让你的应用程序更坚固！

感谢大家！