1、能够协助程序员尽快找到BUG的具体位置
在没有单元测试的时代,我们大多数的错误都是通过操作页面的时候发现的。当我们发现一个错误的时候,会根据异常抛出的地点来确定是哪段代码出现了问题。但是大多数时候,我们不会所有方法中都使用Try块去处理异常(这一也是低效的)。因此一旦发现一个异常通常都是最顶层代码抛出的,但是错误往往又是在底层很深层次的某个对象中出现的。当我们找到了这个最初抛出异常的方法的时候,我们可能无法得知这段代码到底是哪里出了问题。只能逐行代码地去查找,一旦这个方法中使用的某个对象在外部有注册事件或者有其他的操作正在与当前方法同步进行,那么就更难发现错误真正的原因了。
有经验的程序员也会知道,大多数的时候,我们并不是真正的在编写新的代码,而是在修改旧的代码出现的错误。通常这个比例会大于2比8,这也是编写代码的时候的二八现象——编写代码的时间是二,而为这段代码找错误、修改错误所花费的时间却是八。
在这种状态之下,我们在找错误的时候会直接编译整个程序,然后通过界面逐步地操作到错误的地方然后再去查找代码中是否有错误。这样的找错误的方法效率非常低。但是当我们拥有单元测试的时候,我们就不需要通过界面去一步一步的操作,而是直接运行这个方法进行单元测试,将输入的条件模拟成出现错误的时候输入的信息和调用的方法的形式,这样就可能很快的还原出错误。这样解决起来速度就提高了很多,每次找到错误都去修改单元测试,那么下次就不会再出现相同的错误了。
如果通过模拟,单元测试也没有出现任何异常,这时也可以断定,并非该代码出现的错误,而是其他相关的代码出现的错误。我们只需再调试其他几个相关的代码的单元测试即可找到真正的错误。

单元测试可以快速定位BUG,提高修复效率,使程序员对代码更有信心。它在开发早期暴露问题,增强代码健壮性,指导开发过程,并作为代码文档供他人理解。同时,它还能让项目管理者更准确地评估项目进度和代码质量。
最低0.47元/天 解锁文章

880

被折叠的 条评论
为什么被折叠?



