对减少自身 Bug 量的思考

从 去年年底 到 现在, 一直被一个问题困扰着————自己的代码质量过低, 代码质量不佳并不是指代码的封装性或者复用性上, 而是 Bug 量始终高居不下. 时常被同事说要多测试, 但是写完代码要自测的时候又感觉要测试的东西好多, 然后懒癌一犯, 就干别的去了.

虽然这样的事情很多程序员都会有, 但是感觉这样很 Bad, 显得很不专业. 而且最近写的一个东西被部门大佬拿去体验的时候, 十分钟都不到,就因为一个 很小的Bug 导致主流程无法进行,而终止了体验:joy:, 这件事对我有些触动. 便开始找一种比较好的方式去改变这个状况.

问题的根本在于, 我之前希望自己在 写完 Feature 的十分钟内, 想好测试方案. 如果不能实现的话, 就觉得太麻烦, 便不测试了.

然而实际上, 这个是根本不可能实现的, 所以有两种方案供我选择, TDD 和 测试用例列表

1. TDD 显然是一个挺好的办法, 先写一些一劳永逸的测试用例, 然后再写功能代码, 这样功能代码的质量显然有保证的. 但是对我来说 TDD 也有一些缺点.

   1. 一方面是 TDD 会增大我需要维护和书写的代码量, 当功能逻辑进行改变的时候, 我需要相应的改变 TDD 时写下的测试代码.
   2. 另一方面, 当项目时间吃紧的时候, 因为此前并没有 TDD 的经验, 会导致 上面所说的第一个缺点进一步放大, 所以我会更加倾向第二种方案.

2. 使用一个 测试用例列表, 在开发中或者开发前想到的一些测试的点, 记录到我的 TestCaseSet 中, 然后在开发完毕后, 再补充一轮测试用例到 TCS 中, 接着集中书写测试用例并进行测试. 或者我也可以在写完一个 Function 后的测试运行时, 书写测试用例.

显然第二个方法有 TDD 的影子, 但就现在的我来看, 可能第二种方法更加适合我, 在之后的实践过程中, 第二种方法可能逐步依照 TDD 的一些方法论进行改进 , 但最后并不会和 TDD 相同, 毕竟 TDD 是测试驱动开发(Test-Driven development) , 而对于我来说, 更多的则是 “开发驱动测试”.