Day 20：如何撰写测试

今天就书中描述与我个人的开发经验，来谈谈该如何撰写测试吧。有时候我们可能会遇到，软件在开发之初并没有做测试的打算，可能有各种原因，包括时程的压力、只是想快速验证原型等等...但若是专案打算要长期发展的话，缺乏测试势必会造成稳定性逐渐下降，而导致之後难以开发（我在学校参与的某个专案就是如此，中期受不了了便停下开发来写测试）。

我认为区分程序码的重要性会是首要步骤，我们可以透过检视专案当中的各个模组，去比较他们对於使用者的影响会有多大，有的地方出了点 bug 或许无伤大雅，但是某些地方若是引入了 bug 可能会造成难以承受的後果。在着手撰写测试之前，先做好这些排序可以帮助我们更快的感受到测试带来的效益，进而提升撰写测试的动力。

接下来，我想可以先从简单的步骤开始做起，这部分或许跟上个步骤有些冲突，因为测试重要的部分可能需要耗费大量的精力，但其实有些简单的检查或许就可以避免不少麻烦，像是如果是使用 typescript 的专案，若是可以在 CI 的流程里面先跑一下 tsc，至少就可以帮我们抓出一些型别错误，然後程序码的 linting 与排版也是，可以确保提交的程序码采用一致的风格，减少 PR 里面引入无谓的变更，让 reviewer 可以关注真正重要的部分。这些都是我认为可以透过较低的投入产生较高效益的行为。

最後一点，替每个 bug 都建立相对应的测试。若是有做到，我想可以避免将来出现需要一次撰写大量测试的情形，而且我们可以确保撰写出来的测试案例是真的有解决问题的，不会仅仅是自行推测可能会出现的问题。长期下来，便能建构完善的回归测试，避免犯下与过去一样的错误，也能逐渐完善测试的覆盖范围。