谈谈单元测试之

最新推荐文章于 2024-04-24 14:34:23 发布

luyaran

最新推荐文章于 2024-04-24 14:34:23 发布

阅读量1.1k

点赞数 1

分类专栏： php

php 专栏收录该内容

162 篇文章 0 订阅

订阅专栏

为什么要进行烦人的单元测试？

前言

最近，在网上看到过一个调查，调查的内容是“程序员在项目开发中编写单元测试的情况”。当然，至于调查的结果，我想聪明的你已经可以猜到了。高达 58.3% 的比例，一般情况下不写单元测试，只有偶尔的情况才会写写。16.6% 的程序员从来都不写单元测试。只有很少的一部分程序员才会在自己的代码中进行单元测试，并保证方法测试通过。看到这些，你想到了什么？

现状

虽然，这个调查可能会有些片面性，但这也基本反应了国内程序员的开发现状，很少有程序员能够比较认真的去编写单元测试。而且，甚至有的程序员根本就不知道为什么要写单元测试（这一点让我很郁闷）。他们经常会说，公司里不是有测试人员嘛，测试应该是他们要做的事，我们的工作只是开发（这位仁兄肯定没有学过软件工程）。当然，这些并不是偶然的，正如佛经里边说的“因果循环”，有果必有因。那么，到底是什么原因，导致程序员对单元测试这么不感冒呢？

发现

通过与几个朋友的讨论，以及网上的调查，主要有这几种原因，导致程序员对单元测试很排斥，或许说很不以为意。

不知道怎么编写单元测试
项目没有要求，所以不编写
单元测试价值不高，完全是浪费时间
业务逻辑比较简单，不值得编写单元测试
不管怎样，集成测试将会抓住所有的 bug，用不着进行单元测试
在项目的前期还是尽量去编写单元测试，但是越到项目的后期就越失控
为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不能按时完成编码任务，导致项目延期

很显然，这几种原因归根结底，无外乎就是不了解单元测试，自认为很聪明，自己懒不想去测试，对项目的时间、进度把控不好。下面，我将一一进行分析，剖析出程序员的开发心理，以此来给朋友们提个醒，最终聪明反被聪明误。

剖析

不知道怎么编写单元测试

这个问题在于，还没有接触过单元测试，同时，也没有体会过企业级的代码开发。不知道同时也不了解单元测试能带给你什么。设想一下，当你开发完一个功能模块的时候，你如何确定你的模块没有 bug 呢？如果涉及到具体的业务，你会执行 debug 模式，然后一点一点的深入到代码中去查看吗？如果你一直都是这样，那么你早就已经 OUT 了。赶快去了解一下单元测试的工具吧，你会收获很大的。

项目没有要求，所以不编写

这个问题反映出了一种现象，同时也是一种习惯。项目有没有要求，只能说明项目的管理上不严格，并不是程序员不编写单元测试的理由。他们在以往的开发中，并没有养成写单元测试的好习惯。可想而知，他们的代码质量，我就不敢恭维了。给个建议，尝试着写漂亮的代码，之所以因为漂亮，是指得健康、简洁、健壮。当然，完成漂亮的代码就离不开单元测试了。

单元测试价值不高，完全是浪费时间

这种说法其实是错误的。为什么这么说呢？在日常的开发中，代码的完工其实并不等于开发的完工。如果没有单元测试，那么如何保证代码能够正常运行呢？测试人员做的只是业务上的集成测试，也就是黑盒测试，对单个的方法是没有办法测试的，而且，测试出的 bug 的范围也会很广，根本不能确定 bug 的范围，还得去花时间来确定 bug 出在什么地方。难道这就不浪费时间了吗？甚至，这样的方式，时间浪费的会更多。

业务逻辑比较简单，不值得编写单元测试

所谓的业务逻辑比较简单，其实是相对的。当你对某一块业务逻辑很熟悉的时候，你自然会认为它很简单。然而，单元测试的必要性并不是仅仅在于测试代码的功能是否正确，还在于，当其他同事在了解你的业务的时候，能够很快的通过单元测试来熟悉代码的功能，甚至不用去读代码，就能够知道它做了哪些事情。因此，写单元测试不仅是解放了自己，更方便了别人。

项目前期还在尽量写测试，到了后期就失控了

这种问题的原因在于，对项目进度、项目中的技术点研究时间、人员的沟通、业务需求的熟悉程度等没有把控好。这个问题的出现并不是个人的问题，而是反映了项目管理中存在的问题。当然，个人的原因也存在，就是如何在有限的时间里，提高效率。这一点需要大家好好思考一下了。我的建议，多做计划，根据实际情况变更计划。多和项目组长、组成员进行沟通。及时反应项目中存在的问题。

为了完成编码任务，没有足够的时间编写单元测试

这个问题在于，程序员领取的任务较为复杂，或者自己的开发效率有待提高。其实，开发任务是包括编码和单元测试的。在领任务的时候，应该跟据自身的能力，跟组长或经理沟通好，以便留出一定的测试时间。当然，提高自己的编码效率也是很有必要的。至于如何提高开发效率，网上有很多这样的文章，这里就不再赘述了。

重要性

测试常常是程序员十分厌倦的一个活动。测试能给我们带来什么？了解这些是非常重要的，测试不可能保证一个程序是完全正确的，但是测试却可以增强我们对程序完整的信心，测试可以让我们相信程序做了我么期望它做的事情。测试能够使我们尽早的发现程序的 bug 和不足。

一个 bug 被隐藏的时间越长，修复这个 bug 的代价就越大。在《快速软件开发》一书中已引用了大量的研究数据指出：最后才修改一个 bug 的代价是在 bug 产生时修改它的代价的10倍。

当然，我们主要讨论的是单元测试。单元测试是一个方法层面上的测试，也是最细粒度的测试。用于测试一个类的每一个方法都已经满足了方法的功能要求。在开发中，对于自己开发的模块，只有在通过单元测试之后，才能提交到 SVN 库或者 Git 库。

应用

正是由于测试在开发中的重要地位，才会在IT界刮起了 TDD 的旋风。TDD，也就是测试驱动开发模式。它旨在强调在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完成全部功能的开发。

工具

说了这么多，那么都有什么工具（框架）能帮助我们完成可重复的单元测试呢？下面我就介绍几个常用的。这里只介绍 Java 语言的。其他语言的请问谷老师（Google）。

JUnit（推荐使用JUnit4）

JUnit 在日常开发中还是很常用的，而且 Java 的各种 IDE （Eclipse、MyEclipse、IntelliJ IDEA）都集成了 JUnit 的组件。当然，自己添加插件也是很方便的。JUnit 框架是 Java 语言单元测试当前的一站式解决方案。这个框架值得称赞，因为它把测试驱动的开发思想介绍给 Java 开发人员并教给他们如何有效地编写单元测试。

TestNG

TestNG，即Testing Next Generation，下一代测试技术。是根据JUnit和NUnit思想，采用 jdk 的 annotation 技术来强化测试功能并借助XML 文件强化测试组织结构而构建的测试框架。TestNG 的强大之处还在于不仅可以用来做单元测试，还可以用来做集成测试。

这里仅仅是介绍一下有哪些最常用的 Java 单元测试工具，对于如何使用这些工具，在后续的博客中会有介绍，这里就不再多说了。有兴趣的请关注后续的文章。

结束语

俗话说，一屋不扫，何以扫天下。开发中，我们自己的代码都不能保证功能的正确性，那么还有什么效率可言呢？做再多的任务，写再多的代码也只不过是在搭鸡窝，做着机器一样的重复的工作。IT界有一个原则，DRY原则 —— Don't Repeat Yourself ！只有通过对自己的工作不断的检查，不断的测试，才能不断的突破，不断的脱颖而出，当然，你才能不断的提高。

Test Day Day Up！ Experience Day Day Up！ And Money Day Day Up Too！

哎呀妈呀，中国式英语又出来了！

测试工具 JUnit 3

前言

上一篇文章《为什么要进行烦人的单元测试？》讨论了一下现阶段软件开发中，程序员们测试情况的现状。这篇文章中，我打算介绍一下单元测试的工具（插件），并且推荐大家以后在开发中，真正的用上单元测试，用好单元测试。

说明

这篇文章的主题，主要是介绍一下 JUnit 3，虽然 JUnit 3 已经不推荐使用了，但它也曾是风靡一时。这里旨在讨论一下 JUnit 3 的使用，以及它的内部构造，就当是为下一篇文章介绍 JUnit 4 做铺垫吧。之前已经把单元测试的重要性都讲出来了，这里就不再赘述了，直接进入正题。

介绍

JUnit 是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。JUnit 测试是程序员测试，即所谓白盒测试。它是一个 Java 语言的测试框架，多数 Java 的开发环境都已经集成了 JUnit 作为单元测试的工具。

特性

用于测试期望结果的断言（Assertion）
用于共享共同测试数据的测试工具
用于方便的组织和运行测试的测试套件
图形和文本的测试运行器

使用

下载

下载 JUnit 3.8.1.jar 包（这里提供了下载地址）

加入项目

把压缩包中的 junit3.8.1.jar 文件，加入到项目的 classpath 中。

基本流程

写测试类并继承 TestCase 类
写测试方法 testXXX()
写测试套件类，将 test case 加入到 test suite
运行JUnit Test 进行测试

演示代码

[java] view plain copy

package com.tgb.test;
import junit.framework.Assert;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
// 1. 继承 TestCase 类
public class CalculatorTest extends TestCase {
// 2. 测试方法必须以 test 开头
public void testAdd() {
int result = new Calculator().add(1, 2);
Assert.assertEquals(3, result);
}
// 3. 将 testcase 加入 testsuite，可以同时测试多个用例
public static Test suite() {
return new TestSuite(CalculatorTest.class);
}
}

剖析概念

TestCase（测试用例）

当一个类继承 JUnit 的 TestCase 类，即成为一个测试类，而且，测试类中的方法必须以 test 开头，比如：testAdd() 等。

TestSuite（测试套件）

TestSuite 是一组测试，目的在于将相关的测试用例归入一组。当执行一个 Test Suite 时，就会执行组内所有的测试方法，这就避免了繁琐的测试步骤。当然，如果没有为 test case 写 test suite 的话，系统会默认为每个 test case 生成一个 test suite。

Assert（断言）

Assert 用于检查条件是否成立，当条件成立则 Assert 方法通过，否则会抛出异常。例如，Assert.assertEquals(3, result); 判断 result 是否跟期望的3想等，如果想等则通过，否则测试失败。

主要有如下几个断言方法：

assertTrue/False（）：判断一个条件是 true 还是 false。

fail（）：失败，可以有消息，也可以没有消息。

assertEquals（）：判断是否想等，可以指定输出错误信息。注意不同数据类型所使用的 assertEquals 方法参数有所不同。

assertNotNull/Null（）：判断一个对象是否为空。

assertSame/NotSame（）：判断两个对象是否指向同一个对象。

failNotSame/failNotEquals（）：当不指向同一个内存地址或者不相等的时候，输出错误信息。错误信息为指定的格式。

setUp

每次测试方法执行之前，都会执行 setUp 方法，此方法用于进行一些固定的准备工作，比如，实例化对象，打开网络连接等。

tearDown

每次测试方法执行之后，都会执行 tearDown 方法，此方法用于进行一些固定的善后工作，比如，关闭网络连接等。

结束语

JUnit 3 就介绍到这，可以看出，JUnit 3 还是很简单的，只不过在每次编写测试类时，都需要继承 TestCase 类，这就无形之中给测试类增加了一些牵绊。下一篇文章中，我们一起来讨论一下 JUnit 4 的一些新特性，以及是如何简化测试用例的。

不要着急哦，下一篇马上就到。。。

测试工具 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 版本仍然能够很好的兼容旧版本的测试用例。

使用

先来点实在的，看看代码中是怎么使用的。其余的待会再说。

下载

下载 JUnit4.8.1.jar 包（这里提供了下载地址）

加入项目

把 junit4.8.1.jar 文件，加入到项目的 classpath 中。

对比

在代码之前，先让我们看一下 JUnit 4 和 JUnit 3 的区别，看看 JUnit 4 到底简化了哪些东西。

演示代码

[java] view plain copy

package com.tgb;
import static org.junit.Assert.*;
import org.junit.Ignore;
import org.junit.Test;
public class TestWordDealUtil {
// 测试 wordFormat4DB 正常运行的情况
@Test
public void testWordFarmat4DBNormal() {
String target = "employeeInfo";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("employee_info", result);
}
// 测试 null 时的处理情况
@Test(expected=NullPointerException.class)
public void testWordFormat4DBNull() {
String target = null;
String result = WordDealUtil.wordFormat4DB(target);
assertNull(result);
}
// 测试空字符串的处理情况
@Test
public void testWordFormat4DBEmpty() {
String target = "";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("", result);
}
// 测试当首字母大写时的情况
//@Ignore
@Test
public void testWordFormat4DBBegin() {
String target = "EmployeeInfo";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("_employee_info", result);
}
// 测试当尾字母大写时的情况
@Test
public void testWordFormat4DBEnd() {
String target = "employeeInfoA";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("employee_info_a", result);
}
// 测试多个相连字母字母大写时的情况
@Test
public void testWordFormat4DBTogether() {
String target = "employeeAInfo";
String result = WordDealUtil.wordFormat4DB(target);
assertEquals("employee_a_info", result);
}
}

从图中可以看出，TestWordDealUtil 测试类中，有6个测试方法，其中有5个测试方法都已经通过，另外一个抛出了 NullPointerException （空指针）异常，需要注意的是，这里并不是单元测试的失败（Failure），而是测试出现了错误（Error）。那么，这两种有什么区别呢？下面就讨论一下这两者的区别。

JUnit 将测试失败的情况分为两种：Failure 和 Error 。 Failure 一般是由单元测试使用的断言方法判断失败引起的，它表示在测试点发现了问题（程序中的 bug）；而 Error 则是有代码异常引起的，这是测试目的之外的发现，它可能产生于测试代码本身的错误（也就是说，编写的测试代码有问题），也可能是被测试代码中的一个隐藏 bug 。不过，一般情况下是第一种情况。

深入

常用注解

@Before

初始化方法，在任何一个测试方法执行之前，必须执行的代码。对比 JUnit 3 ，和 setUp（）方法具有相同的功能。在该注解的方法中，可以进行一些准备工作，比如初始化对象，打开网络连接等。

@After

释放资源，在任何一个测试方法执行之后，需要进行的收尾工作。对比 JUnit 3 ，和 tearDown（）方法具有相同的功能。

@Test

测试方法，表明这是一个测试方法。在 JUnit 中将会自动被执行。对与方法的声明也有如下要求：名字可以随便取，没有任何限制，但是返回值必须为 void ，而且不能有任何参数。如果违反这些规定，会在运行时抛出一个异常。不过，为了培养一个好的编程习惯，我们一般在测试的方法名上加 test ，比如：testAdd（）。

同时，该 Annotation（@Test）还可以测试期望异常和超时时间，如 @Test（timeout=100），我们给测试函数设定一个执行时间，超过这个时间（100毫秒），他们就会被系统强行终止，并且系统还会向你汇报该函数结束的原因是因为超时，这样你就可以发现这些 bug 了。而且，它还可以测试期望的异常，例如，我们刚刚的那个空指针异常就可以这样：@Test(expected=NullPointerException.class)。再来看一下测试结果。

@Ignore

忽略的测试方法，标注的含义就是“某些方法尚未完成，咱不参与此次测试”；这样的话测试结果就会提示你有几个测试被忽略，而不是失败。一旦你完成了相应的函数，只需要把 @Ignore 注解删除即可，就可以进行正常测试了。当然，这个 @Ignore 注解对于像我这样有“强迫症”的人还是大有意义的。每当看到红色条（测试失败）的时候就会全身不舒服，感觉无法忍受（除非要测试的目的就是让它失败）。当然，对代码也是一样，无法忍受那些杂乱不堪的代码。所以，建议大家都写漂亮的代码。这样人人都喜欢看你的代码。哎，有强迫症的人伤不起啊！

@BeforeClass

针对所有测试，也就是整个测试类中，在所有测试方法执行前，都会先执行由它注解的方法，而且只执行一次。当然，需要注意的是，修饰符必须是 public static void xxxx ；此 Annotation 是 JUnit 4 新增的功能。

@AfterClass

针对所有测试，也就是整个测试类中，在所有测试方法都执行完之后，才会执行由它注解的方法，而且只执行一次。当然，需要注意的是，修饰符也必须是 public static void xxxx ；此 Annotation 也是 JUnit 4 新增的功能，与 @BeforeClass 是一对。

执行顺序

所以，在 JUnit 4 中，单元测试用例的执行顺序为：

每一个测试方法的调用顺序为：

规范

最后，在来说说关于测试的规范，这些规范是从编程规则，以及日常的实践中，由那些大牛们总结出来的。作为后人的我们，在大树下乘凉的同时，更要遵守这些规则，使得大树更加茁壮成长。

单元测试代码应位于单独的 Source Folder 下

此 Source Folder 通常为 test ，这样可以方便的管理业务代码与测试代码。其实，在项目管理工具 Maven 上已经做了这种规范了。在我们自己写代码时，注意一下即可。

测试类应该与被测试类位于同一 package 下

便于进行管理，同时减少引入带测试类的麻烦。

选择有意义的测试方法名

无论是 JUnit 4 ，还是 JUnit 3 ，单元测试方法名均需使用 test<待测试方法名称>[概要描述] ，如 public void testDivideDivisorIsZero() ，很容易知道测试方法的含义。

保存测试的独立性

每项单元测试都必须独立于其他所有单元测试而运行，因为单元测试需能以任何顺序运行。

为暂时未实现的测试代码忽略（@Ignore）或抛出失败（fail）

在 JUnit 4 中，可以在测试方法上使用注解 @Ignore 。在 JUnit 3 中，可以在未实现的测试方法中使用 fail("测试方法未实现"); 以告知失败是因为测试方法未实现。

在调用断言（assert）方法时给出失败的原因

在使用断言方法时，请使用带有 message 参数的 API ，并在调用时给出失败时的原因描述，如 assertNotNull（"对象为空", new Object()）。

结束语

请牢记：测试任何可能的错误。单元测试不是用来证明您是对的，而是为了证明您没有错。

JUnit 4 到这里就差不多了，如果文章中有什么不对的地方，还希望各位大牛拍砖。说了这么多，能真正用上才是王道，当然，希望以我这篇文章为契机，IT 界的精英们，之前没有用单元测试的，能够唤醒你们体内的小宇宙；之前已经在用的，也能够再体会一番，提高开发的效率，写出漂亮的代码。

测试工具 TestNG

前言

上一篇文章《测试工具 JUnit 4》中提到了 JUnit 4，并对 JUnit 4 做了简单的讨论，这篇文章我们将要围绕另一款测试工具讨论 —— TestNG。其实，这篇文章应该写在《测试工具 JUnit 3》之后，和《测试工具 JUnit 4》之前，为什么这么说呢？

那是因为，TestNG 是在 JUnit 3 之后出来了，而 JUnit 4 是在 TestNG 推出之后，综合 JUnit 3 的优点，并且借鉴了 TestNG 的优势，才推出的。但是，考虑到，JUnit 3 、4 都是 JUnit 系列的，所以就放到一块了，而没有把他们分开。所以，大家知道这里的关系就好了。

简介

TestNG是一个用来简化广泛的测试需求的测试框架，从单元测试（隔离测试一个类）到集成测试（测试由多个类多个包甚至多个外部框架组成的整个系统，例如应用服务器）。

步骤

编写测试的业务逻辑并在代码中插入 TestNG Annotation
将测试信息添加到 testng.xml 文件或者 build.xml 中
运行 TestNG

一些概念

suite（套件）

由 xml 文件描述，它包含一个或多个测试并被定义为 <suite> 标签。

test（测试）

由 <test> 描述，并包含一个或者多个 TestNG 类。

class（类）

由一个或多个方法组成。

注解

@BeforeSuite

被注解的方法，会在当前 suite 中所有测试方法执行之前被调用。

@AfterSuite

被注解的方法，会在当前 suite 中所有测试方法执行之后被调用。

@BeforeTest

被注解的方法，会在测试（原文就是测试，不是测试方法）运行之前被调用。

@AfterTest

被注解的方法，会在测试（原文就是测试，不是测试方法）运行之后被调用。

@BeforeGroups

被注解的方法，会在执行组列表中之前被调用。这个方法会在每个组中第一次测试方法调用之前被调用。

@AfterGroups

被注解的方法，会在执行组列表中之后被调用。这个方法会在每个组中最后一个测试方法调用之后被调用。

@BeforeClass

被注解的方法，会在当前类第一个测试方法运行之前被调用。

@AfterClass

被注解的方法，会在当前类所有测试方法运行之后被调用。

@BeforeMethod

被注解的方法，会在运行每个测试方法之前被调用。

@AfterMethod

被注解的方法，会在每个测试方法运行之后被调用。

配置

调用 TestNG 有几种不同的方法，使用 testng.xml 文件，使用 ant ，从命令行敲命令。当然，使用 Java IDE的话，可以不用写 testng.xml 文件，不过不代表用不到，只不过是 IDE 会自动生成一个 testng.xml 文件，不用你再手动的写了。如果从学习的角度来看，testng.xml 文件的配置，我们还是要学的，最起码要了解它是怎么配置的，以便看到它了不会感到陌生。

testng.xml 文件可以到 testng 的官网去 copy ，官网介绍的很详细（如果你英文还说的过去，建议去官网）。

[html] view plain copy

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="Suite1" verbose="1" >
<test name="Nopackage" >
<classes>
<class name="NoPackageTest" />
</classes>
</test>
<test name="Regression1">
<classes>
<class name="test.sample.ParameterSample"/>
<class name="test.sample.ParameterTest"/>
</classes>
</test>
</suite>

当然，你还可以指定包名替代类名，就像这样：

[html] view plain copy

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="Suite1" verbose="1" >
<test name="Regression1" >
<packages>
<package name="test.sample" />
</packages>
</test>
</suite>

不止这些，你同样可以指定包含或不包含的组和方法，Such as：

[html] view plain copy

<test name="Regression1">
<groups>
<run>
<exclude name="brokenTests" />
<include name="checkinTests" />
</run>
</groups>
<classes>
<class name="test.IndividualMethodsTest">
<methods>
<include name="testMethod" />
</methods>
</class>
</classes>
</test>

你同样可以在 testng.xml 中定义新的组，指定属性的额外详细情况，比如：是否并行运行测试，使用多少线程，是否运行 JUnit 测试，等等。。。

至于，运行 TestNG 的那些命令，官网上已经说的很清楚了，如果你需要中文的资料，那么我不会告诉你去找 Goo哥或者 Baidu，这里就不再赘述了。需要注意一点的是，TestNG 需要的 JDK 版本是 1.5 以上的。为什么这样，想想 JDK 1.5 的新特性，我想你已经知道了，这里就不再废话了。

生命周期

使用 TestNG，不仅可以指定测试方法，还可以用专门的标注 @Configuration指定类中的其他特定方法，这些方法叫做配置方法。配置方法有四种类型：

beforeTestClass 方法在类实例化之后，但是在测试方法运行之前执行。
afterTestClass 方法在类中的所有测试方法执行之后执行。
beforeTestMethod 方法在类中的任何测试方法执行之前执行。
afterTestMethod 方法在类中的每个测试方法执行之后执行。

结束语

本篇文章，主要是介绍了 TestNG 的基本功能，当然，TestNG 是非常强大的，这里没有时间细说，最后分享一个小例子，想学 TestNG 的可以下载下来运行一下。例子非常简单，可以通过与 JUnit 4 的例子进行对比，你就会发现，其实，他们还是都差不多的。毕竟，JUnit 4 也借鉴了 TestNG 的设计。

学好测试，编写健壮、漂亮的代码，节省下更多的时间学学新技术，陪陪家人，不也都挺好嘛。干嘛非要跟自己过不去，让那些混乱的代码逼着自己加班，你说是吧？

luyaran

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
谈谈单元测试之

为什么要进行烦人的单元测试？前言最近，在网上看到过一个调查，调查的内容是“程序员在项目开发中编写单元测试的情况”。当然，至于调查的结果，我想聪明的你已经可以猜到了。高达 58.3% 的比例，一般情况下不写单元测试，只有偶尔的情况才会写写。16.6% 的程序员从来都不写单元测试。只有很少的一部分程序员才会在自己的代码中进行单元测试，并保证方法测试通过。看到这些，你想到了什么？
复制链接

扫一扫

专栏目录