1、能够协助程序员尽快找到BUG的具体位置

  在没有单元测试的时代,我们大多数的错误都是通过操作页面的时候发现的。当我们发现一个错误的时候,会根据异常抛出的地点来确定是哪段代码出现了问题。但是大多数时候,我们不会所有方法中都使用Try块去处理异常(这一也是低效的)。因此一旦发现一个异常通常都是最顶层代码抛出的,但是错误往往又是在底层很深层次的某个对象中出现的。当我们找到了这个最初抛出异常的方法的时候,我们可能无法得知这段代码到底是哪里出了问题。只能逐行代码地去查找,一旦这个方法中使用的某个对象在外部有注册事件或者有其他的操作正在与当前方法同步进行,那么就更难发现错误真正的原因了。

  有经验的程序员也会知道,大多数的时候,我们并不是真正的在编写新的代码,而是在修改旧的代码出现的错误。通常这个比例会大于2比8,这也是编写代码的时候的二八现象——编写代码的时间是二,而为这段代码找错误、修改错误所花费的时间却是八。

  在这种状态之下,我们在找错误的时候会直接编译整个程序,然后通过界面逐步地操作到错误的地方然后再去查找代码中是否有错误。这样的找错误的方法效率非常低。但是当我们拥有单元测试的时候,我们就不需要通过界面去一步一步的操作,而是直接运行这个方法进行单元测试,将输入的条件模拟成出现错误的时候输入的信息和调用的方法的形式,这样就可能很快的还原出错误。这样解决起来速度就提高了很多,每次找到错误都去修改单元测试,那么下次就不会再出现相同的错误了。

  如果通过模拟,单元测试也没有出现任何异常,这时也可以断定,并非该代码出现的错误,而是其他相关的代码出现的错误。我们只需再调试其他几个相关的代码的单元测试即可找到真正的错误。

  

单元测试能带来的好处_单元测试

  2、能够让程序员对自己的程序更有自信

  很多时候,当主管问我们程序会不会再出问题的时候,我们会很难回答。因为我们没法估计到系统还可能出现什么问题。但是如果这时我们为所有代码都编写了单元测试,而且测试代码的编写是按照标准去写的,这些测试又都能够成功地通过测试。那么我们就完全有自信说出我们的把握有多大。因为在测试代码中,我们已经把所有可能的情况都预料到了,程序代码中也将这些可能预料到的问题都解决了。因此我们会对自己的程序变得越来越自信。

  3、能够让程序员在提交项目之前就将代买变得更加健壮

  大多数程序员在编写代码的时候,都会先考虑最理想化情况下的程序该如何写,写完之后在理想状态下编译成功,然后输入理想的数据发现没有问题。他们就会自我安慰地说“完成了”。然后可能为了赶进度,就又开始做另外的程序了。时间久了这种理想化的程序就越来越多。一旦提交测试,就发现这里有错误那里有错误,然后程序员们再拿出时间来这里补个漏洞那里补个漏洞。而且在补漏洞的过程中,也可能继续沿用这种理想化的思路,就导致了补了这里又导致那里出问题的情况。

  但是如果在初期,我们就为每段代码编写单元测试,而且根据一些既定的标准去写,那么单元测试就会提前告诉程序员哪些地方会出现错误。那么他们可能在编写过程中就提前处理了那些非理想状态下的问题。这样我们的代码就会健壮很多。

  4、能够协助程序员更好地进行开发

  “码未动,测试先行。”这是极限编程中倡导的一种编程模式,为什么要这样做呢?因为我们在编写单元测试的过程中,其实就是在设计我们的代码将要处理哪些问题。单元测试写的好,就代表你的代码写的好。而且你会根据单元测试的一些预先设想的情况去编写代码,就不会盲目地添加一个属性、添加一个方法了。

  5、能够向其他程序员展现你的程序该如何调用

  通常情况下,单元测试代码中写的都是在各种情况下如何调用那段待测试的代码。因此这个单元测试同时也向其他人员展示了我们的代码该如何调用?在什么情况下会抛出什么异常?等等。这样一个单元测试就变成了一个代码性的帮助文档了。

  6、能够让项目主管更了解系统当前的状况

  传统的管理中,项目的进度、代码的质量都只是通过口头的形式传递到主管那里的。因此有时候主管获得的反馈可能是事实。但是如果通过一个完善的单元测试系统,那么主管就可以通过查看单元测试的运行结果和单元测试的代码覆盖率来确定开发人员的工作是否真正完成。

  如需了解更多测试技术信息请关注:深圳多测师软件与技术服务有限公司