论单元测试之重要性

单元测试的重要性不言而喻,自我开发生涯以来,从很少注释过过场场,到非常重视。

单元测试为什么会让人忽视呢?

通常情况像一些查询或者增删改之类,拿我来说,即便报错我大概一扫,我就知道错误是什么了,该如何排查,因为就拿SpringMVC来说或者MyBatis等,再不济就是Spring的依赖注入问题,拿MyBatis来说,要么就是sql问题,要么就是参数问题,再不济就是与Spring动态扫描有关或者是mybatis中专门写sql的配置文件某个地方语法错误等,这些错误都是可预见的,说句不好听的话,再不济百度一搜,顿时分分秒就KO了。但是大家有没有想过这样一个问题?为什么我们老是在犯这些重复性错误呢?原因是什么呢?

不重视测试。

当然了就专业来说,我们是软件开发工程师,专注于开发,至于测试方面,我们又不是专门的测试,管我们什么事。

我只能说:此言差异。

为什么呢?

坦白的说,程序的Bug基本都是由于我们这些开发人员导致的,比如说代码风格乱七八糟,写完代码看到功能实现了,就什么都不管了,也不多测测,以至于每次都是测试人员来测,发现谁的错误就通知谁,而谁谁就开始改了。

我认真想了下,其实很多错误是可以避免的。

就拿我公司来说,我们没有测试没有前端没有运维,而我作为Java后台开发,同时兼任前端、测试、运维,记得在第一个项目初期时,为了加快项目进度,尽快让老板看到对应的效果,我们快速开发,能粘贴复制尽量不手写,遇到问题百度搜索,找到对应的解决方案,代码复制过来,看能不能跑起来,能跑起来,就不管了,功能实现就好,跑不起来,继续百度或者Google,当然一般情况百度比较多。

前期项目急,甚至表单校验懒得写,甚至有些代码注释都不写,命名的话想到规范就规范,想不起,凑合吧,对于那时的我来说,这些都不是最重要的,最重要的是,每周完成工作任务,提交代码,功能实现。当然欲速则不达,再怎么快,总会因为这样的错,那样的错导致项目进度延迟。而且这些错误是可以完全避免的。

比如我们使用的框架是Spring+MyBatis+SpringMVC,采用的表现层技术是JSP,数据库为MySQL。

JSP对于广大的Java同行们,并不陌生。

话走的有点偏。本篇着重与凸显单元测试之重要性。

进入正题:

无论是前后端分离开发,还是想我上述列出的前后端不是特别分离的jsp技术等,单元测试起到不可估量的作用。

我总结到,为什么表现层方面就会出现这样的那样的错误,关键在于控制层代码有问题,也就是Controller层。

通常情况下,像我现在开发,通常Controller代码,我会通过单元测试测试好几遍,当然也做条件,这样的话,可以避免一些简单的错误,什么空指针,参数问题等等。而且对于表单提交方面的,例如注册、添加用户、批量增加或者修改等,都是可以通过单元测试测试是否正常。

记得某位朋友曾经说过,从单元测试到业务测试再到UI测试(WEB测试),越底层,花费的时间成本越小,很容易找到错误,越到高层越不易排错,当然了,排错的方式也很重要。

这里我想说的是,尽量能在单元测试可以预见错误的前提下,尽量排错错误的可能性,因为到WEB阶段是非常让人痛苦的。

越简单的事情往往都会让人忽略的,坦白的说吧,我发现一个很贴近现实的情况,就是我们开发人员,就我个人而言,有的时候觉得存在Bug,除非其他同事发现了,说了下,或者实际业务出问题,不然我不会改的,也懒得改。我想这是我半年前的心理。现在的我以写的代码让人尽可能容易让同事看的懂,尽量简洁,同时现在我对于我写的代码,我可以清楚的知道它是如何跑起来的,会出现哪些问题。当然了,对于一些简单的低级错误,我现在已经通过单元测试排除掉了。而且再加上严格的表单校验。统一规范的js书写和每天十到十五分钟早会的汇报和简单交流及其加强沟通的情况下,我们的Bug越来越少了,代码整体的性能也越来越好,简洁优美,当然了,这还远远不够,相对于第一个项目而言,我们的第二个项目一直到现在的第三个项目,越来越好了。希望继续努力保持下去。

另外补充到:

对于前后端交互,无论是AJAX或者vue.js等等,SpringMVC的Controller代码,基本上都是可以通过单元测试得到结果的,单元测试过了,自然出错率会减少很多。

当然了,我说的单元测试,不是简单的运行就可以了,而是有条件的列出实际情况,这需要根据实际业务情况而定,当然了也不能总是在单元测试了,毕竟开发进度要保持增长。

总结:

上面的描述,也许不好理解,也许重点不突出。下面我要列出我认为重要的几点?

(1)小公司而言,后台兼任前后台开发,确保后台参数,可以在前台校验的,尽量放在后台,这对于减轻服务器负载非常有帮助;

(2)controller代码中的各个@RequestMapping下的代码是可以通过单元测试避免很多错误的,例如空指针或者sql有误或者传参类型问题或者resultType或resultMap常见的问题等,这些是可以避免的;

(3)写代码,无论是js或者Java代码,一定要清楚的知道它是如何运行的,这里说的,并不是要你知道非常清晰的每一步,因为那是计算机底层原理,这个底层原理我也不懂,正在学习中。我所说的知道它是如何运行的,是指,你能通过大脑想象,描述它是怎么走了,比如这个参数传到这个,但是参数值有误,会出现什么情况等等这样的情况,这样可以确保你的思维是清楚,思维的清楚,也代表代码逻辑的清楚。作为开发人员,连自己的代码都不知道怎么描述,说个所以然来,那么他的代码是非常糟糕的;

(4)代码,以追求简单易懂,清楚明了为主,让维护的人易维护,让几个月后的自己感谢自己。更让整体系统性能更好。其实,很多简单的事情堆积起来就是一件不平凡的事情。

以上就说这么多了,欢迎编程的友友们不吝赐教。

原文地址:https://www.cnblogs.com/youcong/p/9291184.html

时间: 2024-07-30 16:57:54

论单元测试之重要性的相关文章

单元测试之NSNull 检测

Unit Testing: 单元测试 测试这个词很容易理解,那么什么是单元(Unit)呢?一个单元指的就是应用程序中可以测试的最小单元.一组源代码可以测试,一般要求有明确的输入与输出.因此一般来说源代码中明确的包含输入输出的每一个方法被认为一个测试的单元(一个case).注意,这里的输出并不局限于方法的返回值对输入参数的改变,也包括方法在执行过程中改变的任何数据. 单元测试在程序里面可以理解一个模块一个方法,在每个可能存在的模块都进行测试,确保每个模块都没有问题,从而提高整体程序的质量. 单元测

补习系列-springboot 单元测试之道

目录 目标 一.About 单元测试 二.About Junit 三.SpringBoot-单元测试 项目依赖 测试样例 四.Mock测试 五.最后 目标 了解 单元测试的背景 了解如何 利用 springboot 实现接口的测试 了解如何 利用 mokito 做代码的 mock 一.About 单元测试 单元测试其实是一种廉价的技术,是由开发者创建运行测试代码,用于对程序模块(软件设计的最小单位)进行正确性检验的一种做法. 而所谓的最小单元,就是指应用的最小可测试部件. 在面向对象领域,最小单

单元测试之Stub和Mock

单元测试之Stub和Mock FROM:http://www.cnblogs.com/TankXiao/archive/2012/03/06/2366073.html 在做单元测试的时候,我们会发现我们要测试的方法会引用很多外部依赖的对象,比如:(发送邮件,网络通讯,记录Log, 文件系统 之类的). 而我们没法控制这些外部依赖的对象.  为了解决这个问题,我们需要用到Stub和Mock来模拟这些外部依赖的对象,从而控制它们 阅读目录 实例 设计测试用例 什么是外部依赖 Stub和Mock的相同

谈谈单元测试之(四):测试工具 TestNG

前言 上一篇文章<测试工具 JUnit 4>中提到了 JUnit 4,并对 JUnit 4 做了简单的讨论,这篇文章我们将要围绕另一款测试工具讨论 -- TestNG.其实,这篇文章应该写在<测试工具 JUnit 3>之后,和<测试工具 JUnit 4>之前,为什么这么说呢? 那是因为,TestNG 是在 JUnit 3 之后出来了,而 JUnit 4 是在 TestNG 推出之后,综合 JUnit 3 的优点,并且借鉴了 TestNG 的优势,才推出的.但是,考虑到,

谈谈单元测试之(三):测试工具 JUnit 4

前言 上一篇文章<测试工具 JUnit 3>简单的讨论了 JUnit 3 的使用以及内部的方法.这篇文章将会在 JUnit 3 的基础上,讨论一下 JUnit 4 的新特性.同时,与 JUnit 3 做一个简单的对比.那么,废话就不多说了,直接进入正题. 介绍 JUnit 4.x 是利用了 Java 5 的特性(Annotation)的优势,使得测试比起 3.x 版本更加的方便简单,JUnit 4.x 不是旧版本的简单升级,它是一个全新的框架,整个框架的包结构已经彻底改变,但 4.x 版本仍然

单元测试之测试方法

单元测试面临的困难 职责不明确 类或者方法的职责不明确,违反了SRP原则. 类/方法如果处理了本不该它处理的逻辑,会造成单元测试需要关心过多的外部关联类. 静态方法 静态方法使得调用者直接面对实际的服务类,难以通过其它方式替代其实现,也难以扩展. 直接访问对象实例 调用者直接实例化服务对象,从而使用服务对象提供的服务.同静态方法一样,调用者直接面对服务类. 标准库 标准库中有非常多的接口调用使得调用者难以被测试. 准备数据 编写测试用例需要外部准备大量的数据. 可行的解决方案 重构系统 对于职责

我的单元测试之总结

单元测试 版权声明:本文为博主原创文章,未经博主允许不得转载. 以下关于单元测试的总结,是基于目前工作的内容进行的汇总,包括了单元测试的定义,单元测试assertion语句,单元测试的框架以及实践中的注意事项等.其中[***]为解释说明.在此推荐几本有关单元测试的书籍供参考.<单元测试的艺术><单元测试之道junit(Java版)><单元测试之道Nunit(C#版)>. Overview 一个UT当中,包括了准备数据,释放资源,执行要验证的那段逻辑代码,以及结果的验证等

Visual Studio 单元测试之二---顺序单元测试

原文:Visual Studio 单元测试之二---顺序单元测试 此文是上一篇博文:Visual Studio 单元测试之一---普通单元测试的后续篇章.如果读者对Visual Studio的单元测试不熟悉的话,请先参看上一篇.http://blog.csdn.net/tjvictor/archive/2011/02/09/6175362.aspx 本文会自动略去上篇中提到过的相关概念.方法.本文的例子可以使用下面的链接下载: http://download.csdn.net/source/30

单元测试之Mock

为什么需要Mock. 真实对象具有不确定的行为.所以会产生不可预测的结果. 真实对象很难被创建. 真实对象的某些行为很难被触发(如网络错误). 真实对象令程序的运行速度很慢. 真实对象有(或者是)用户界面. 测试需要询问真实对象它是如何被调用的. 真实对象实际上并不存在.例如其它小组开发的模块. 使用Mock的3个步骤 使用一个接口来描述该对象. 为产品代码实现该接口. 以测试为目的,在Mock对象中实现该接口. Test Double Dummy.被传递但是从不被实际使用的对象.通常用于填充参