测试成本

# 一、灵魂深处的拷问

• 你的代码质量如何度量？
• 你是如何保证代码质量？
• 你敢随时重构代码吗？
• 你是如何确保重构的代码依然保持正确性？
• 你是否有足够信心在没有测试的情况下随时发布你的代码？

📢 如果答案都比较犹豫，那么就证明我们非常需要单元测试。(ps: 不会有人心里想的是我们需要测试同学吧 😏)

它能带给我们很多保障：

• 代码质量持续有保障
• 重构正确性保障
• 增强自信心
• 自动化运行

Web 应用中的单元测试更加重要，在 Web 产品快速迭代的时期，每个测试用例都给应用的稳定性提供了一层保障。 API 升级，测试用例可以很好地检查代码是否向下兼容。 对于各种可能的输入，一旦测试覆盖，都能明确它的输出。 代码改动后，可以通过测试结果判断代码的改动是否影响已确定的结果。

所以，应用的 Controller、Service、Common、Manager 等代码，都必须有对应的单元测试保证代码质量。 当然，框架和插件的每个功能改动和重构都需要有相应的单元测试，并且要求尽量做到修改的代码能被 100% 覆盖到。

特别是中大型项目，经过多年的代码迭代，业务逻辑复杂，代码改动很容易牵一发动全身， 单元测试就能给应用的稳定性提供了一层保障。不用面对qa的灵魂拷问：

# 二、单测是手段不是目的

单测行覆盖率高不代表应用的质量就一定高,但是单测行覆盖率低一定代表着这个应用出现质量问题的可能性就越大

还是引用前面话,我们不要为了单测而写单测,如果是把单测当做是目的来做,那么就偏离了单测的意义,自然而然你就认为 这个单测的成本是高的。... ... ... ... ... ... ... 你品你细品

# 三、软件的质量不是测试出来的，而是设计和维护出来的

作为底层开发人员, 我们清晰每一行代码, 也就是最小执行单元。哪里容易出现错误，这次改造涉及到了那些代码。一线开发人员一定是最清楚的人,没有之一。

从这个角度来了, 这就不是成本的问题了, 是职责范围内的事情。

如果单元测试都不做,就好比我去街上买鸡蛋, 我问老板鸡蛋是好是坏, 老板说我不知道, 然后说坏了拿来可以换。 你认为那个成本更大呢? 那个代价更大呢? 玩意坏鸡蛋把人吃坏了，这老板岂不是赔了夫人又折兵,还要受到法律的制裁?