为什么要写测试

提高开发效率

一般开发流程中存在两个步骤：代码写完，手动调试

在手动调试开始前需要大量的准备工作。例如对一条数据的删除行为，在调试前需要经过启动项目、手动增加一条数据两个步骤之后才能开始正式的删除行为。而有时调试过程中，因为各种原因会忽略某些数据，而为了获取这些数据只能选择重复进入调试

每次手动调试都只能携带一种状态，如果逻辑中存在判断分支，每一个分支都需要进行一次验证

单元测试可以替换手动调试，避免了手动调试存在的这两个问题

另一方面，单元测试可以保留调试时的步骤，方便步骤的复用

主要面向对代码进行改动时的场景

在完成功能新增或 bug 修复之后，需要判断改动是否会影响已实现功能。如果老功能的数量繁多或逻辑十分复杂，手动测试的时间消耗无疑是一种负担，以致于形成一种靠运气编程的情况，开发者需要祈祷本次提交不会破坏老功能的实现，这无疑会打击开发者的自信心

而在单元测试中，对于老功能的测试步骤是保留的，新的改动只需要满足之前测试通过就可以判定对老功能的影响有限，这必然会减轻开发者的心智负担以及对自身代码的怀疑

能跑就行，不敢动，引入 bug 谁负责？但是重构可以提升代码质量，好的代码质量可以提升功能开发的效率，而越差的代码质量所引起的 bug 就越多

项目生命周期：从头开始，加功能都很轻松；功能越来越多，bug 越来越多；重写项目

这种技术债务本质就是代码的质量问题，需要不停的重构来改善代码质量，而测试可以改善无意义的开发负担

除了自己的代码，还需要保证他人的代码质量，需要测试的参与

在写单测的时候就已经将功能的行为、输入、输出都记录下来了，回顾时只需要查阅单测，在形式上单测具备了文档的功能

糟糕的程序设计根本无法建立单测，从某种意义上说，单测可以倒逼程序架构封装

单测的程序必须符合 SOLID 原则，实现高内聚低耦合的代码标准