找到
5
篇与
单元测试
相关的结果
-
无单测、不编码——写单元测试的重要性 作为一个开发人员。很多人很少写单元测试，甚至不写单元测试。 总结一下开发人员不写单测的原因无非有以下几种： 1、认为写单测浪费时间。 2、认为测试不应该是开发人员来做的。 3、自信我写的代码没有问题，不需要单测。 4、不知道单测的重要性。 5、不知道单测的好处。 那么针对以上这几种观点，今天就逐个分析一下。到底单元测试有没有那么重要。 单元测试真的浪费时间吗？ 在业务高速发展的今天，很多时候项目来的时候要的都很急。好像要是我不把这个功能在几天之内搞完整个公司都要倒闭了一样。所以，很多开发人员都把主要的时间用在写业务逻辑代码上。很多人都是有时间的时候才会写一些简单的单元测试代码，如果项目比较忙的话就不写单元测试。 很多程序员的项目都是这样完成的： 写代码---->集成测试---->改bug---->集成测试---->预发布测试---->改bug---->正式发布---->发生故障---->改bug---->发布---->改bug---->.... 可以看到，改bug过程贯穿着整个软件的生命周期。改bug很多人都知道怎么改，就是要先定位问题，然后再解决问题。往往定位问题都是比较复杂的，一般都需要很长的时间。 如果有了单元测试可能就会节省很多时间，通过单测可以减少很多bug的发生，也能帮助我们快速的定位问题。只要在集成测试之前做好单元测试。在通过单元测试之后，我们就可以认为这部分代码是可靠的，那么就可以放心的进行项目集成。 当然，有了单元测试，并不能保证代码不出现bug。但是，单元测试可以在软件开发过程的早期就能发现问题。只要单测的测试用例足够好，那么就可以避免很多低级错误。 那么，为什么还是很多人认为单元测试浪费时间呢，个人分析原因可能是这样的。开发人员认为我的时间就应该用来写业务逻辑代码。项目出现了bug，我也应该用我的时间来解决这个bug。他们认为我的时间花费在这件事上我是认可的，所以我的时间就不叫浪费。归根结底，他们就是没有意识到单元测试所带来的好处。一旦他们发现，通过单元测试可以让我更早的发现问题等等好处，那么他们也会认可把时间花费在写单测上。 在这里，可以先下一个结论：好的单测不仅不会浪费时间，还会大大节省我们的时间。至于为什么会节省时间以及什么叫好的单测会在后面介绍。 单元测试应不应该开发人员来写 这里暂不分析到底应不应该有单独的测试人员，这是一个颇有争议的话题（一部分人认为，开发就应该是全栈的。还有一部分人认为开发就应该只关注业务写业务代码）。这里只分析单元测试到底应该由谁来做。有人认为，单元测试也是测试的一种手段，应该交给专门的QA去做。也有人认为单元测试应该是开发人员来写，那么，单元测试到底应不应该开发人员写呢？ 单元测试必须由最熟悉代码的人来写。这是好的单元测试的标准之一。那么还能有谁比写代码的人更了解代码呢？代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。单独的测试人员进行单元测试，往往工作量大，周期长，耗费巨大，其结果事倍功半。软件的开发者总是应当负责程序的单个单元的测试，保证每个单元能够完成设计的功能，其实在很多情况下，开发者也应进行集成测试。 我的观点以为，开发人员写了一个函数，就要对这个函数负责，就有义务保证这个函数可以准确的执行。单测便是一个很好的手段。所以，如果要写单测，就应该开发人员自己来写。 我很自信，我还需要单测吗？ 有人能写出完美无缺的代码么？答案是否定的！ 我认为程序员都是天生骄傲的。虽然程序员往往都会说：在我机器上明明是好的呀，是不是你用的方式不对呀。但是，好的程序员应该在说完这句话之后会偷偷的去排查问题。 写代码不是可以一蹴而就的，必须经过各种各样的测试，单元测试只是其中一种。 所以，无论你是一个多么天生骄傲的程序员，你都不是神！所以，你也需要单测。 单测真的有那么重要么？ 很多程序员宁愿把时间花费在写业务逻辑代码上，他们多数是有时间的时候才会写一些简单的单元测试代码，如果项目比较忙的话就不写单元测试。据我所知，只有少数的公司会要求项目上线必须达到一定百分比的代码覆盖率（软件测试中的一种度量，描述程式中源代码被测试的比例和程度），大多数公司都不是很重视这一项，所有，很多人就不太重视单元测试。但是，很多发生故障的经验告诉我们，很多问题是可以通过单元测试避免的。 其实单元测试的重要性很简单，就是一句话：不写单元测试，你怎么知道你的代码写的对不对？没有足够丰富的测试用例，你怎么知道用户会怎么使用到你的代码，你又怎么会知道你的代码应该怎么被执行呢？ 所以，单元测试很重要。和写代码一样重要。无单测，不编码！ 单元测试有哪些好处？ 前面说了这么多，其实以上这些问题都有一个最最根源的问题，那就是很多程序员不写单测的最最根本原因是他们根本不知道写单测和不写单测的区别。不知道写了单测能带来好处。所以他们会认为写单测是浪费时间，所以他们才会认为单测不应该是由我来写，所以他们才会认为我不需要写单测。 那么，单元测试到底能带来哪些好处呢？ J.Timothy King写过一篇关于先写单元测试有哪些好处的文章：Twelve Benefits of Writing Unit Tests First（先写单元测试的十二个好处），这里挑其中几个显而易见和比较突出的好处介绍一下。 减少bug 单元测试的目的就是通过足够准确的测试用例保证代码逻辑是正确。所以，在单测过程中，必然可以解决一些bug。因为，一旦某条测试用例没有通过，那么我们就会修改被测试的代码来保证能够通过测试。 减少修复bug的成本 一般解决bug的思路都是先通过各种手段定位问题，然后在解决问题。定位问题的时候如果没有单元测试，就只能通过debug的方式一点一点的追踪代码。解决问题的时候更是需要想尽各种方法来重现问题，然后改代码，改了代码之后在集成测试。 因为单元规模较小，复杂性较低，因而发现错误后容易隔离和定位，有利于调试工作。 帮助重构，提高重构的成功率 我相信，对一个程序员来说最痛苦的事就是修改别人的代码。有时候，一个很大的系统会导致很多人不敢改，因为他不知道改了一个地方会不会导致其他地方出错。可以，一旦有了单元测试，开发人员可以很方便的重构代码，只要在重构之后跑一遍单元测试就可以知道是不是把代码“改坏了” 提高开发速度 不写单测也许能让开发速度更快，但是无法保证自己写出来的代码真的可以正确的执行。写单测可以较少很多后期解决bug的时间。也能让我们放心的使用自己写出来的代码。整体提高开发速度。 后记 据我说知，在facebook是没有QA的，他们的所有代码都是通过单元测试来保证能够正确执行的。在google也很重视单测，国外这样的大公司都会要求单测的代码覆盖率达到一个高的水平，否则是绝对不会允许代码发不到线上的。 所以，通过这样一篇文章，希望读者可以重视单元测试，并在实际项目中运用起来。但是，也请记得，单测只能在一定程度上减少bug的发生，并不是写了单测就不会在发生问题。 无单测，不编码！
-
单元测试第四弹——使用Mock技术进行单元测试 碰撞测试是汽车开发活动中的重要组成部分。所有汽车在上市之前都要经过碰撞测试，并公布测试结果。碰撞测试的目的用于评定运输包装件在运输过程中承受多次重复性机械碰撞的耐冲击强度及包装对内装物的保护能力。说简单点就是为了测试汽车在碰撞的时候锁所产生的自身损伤、对车内人员及车外人员、物品等的损伤情况。 在进行汽车的碰撞测试时，当然不能让真人来进行测试，一般采用假人来测试。但是为了保证测试的真实性及可靠性，假人的生物力学性能应该和人体一样——比如身体各部分的大小和质量，以及关节的刚性等等，只有这样使用它们的模拟才能和现实相匹配。为了保证覆盖到的情况够全面，一般都会使用各种不同的假人，不同的假人模拟男性或者女性的身体，以及不同身高和年龄的人体。 想想软件测试，其实和汽车的碰撞测试流程差不多。一个软件在发布上线之前都要经过各种测试，并产出测试报告，更严格的一点的要保证单测覆盖率不能低于某个值。和汽车碰撞测试类似，我们在软件测试中也会用到很多“假人”。用这些“假人”的目的也是为了保证测试有效的进行。 why 不知道你在日常开发中有没有遇到过以下问题或需求： 1、和别人一起做同一个项目，相互之间已经约定好接口。然后你开始开发，开发完自己的代码后，你想测试下你的服务实现逻辑是否正确。但是因为你依赖的只是接口，真正的服务还有开发出来。 2、还是和上面类似的场景，你要依赖的服务是通过RPC的方式调用的，而外部服务的稳定性很难保证。 3、对于一个接口或者方法，你希望测试其各种不同情况，但是依赖的服务的执行策略及返回值你没办法决定。 4、你依赖的服务或者对象很难创建！(比如具体的web容器) 5、依赖的对象的某些行为很难触发！（比如网络异常） 6、以上问题你都没有，但是你要用的那个服务他处理速度实在是太慢了。 上面这些情况都是日常开发测试过程中可能遇到的比较麻烦的问题。这些问题都会大大的提高测试成本。可以说，很多开发人员不愿意写单元测试很大程度上都和以上这六点有关系。 幸运的是，Mock对象可以解决以上问题。使用mock对象进行的测试就是mock测试。 what mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。 mock对象，就是非真实对象，是模拟出来的一个对象。可以理解为汽车碰撞测试的那个假人。mock对象就是真实对象在调试期间的代替品。 你创建这样一个“假人”的成本比较低，这个“假人”可以按照你设定的“剧情”来运行。 在Java的单元测试中，很多Mock框架可以使用，用的比较多的有easymock、mockito、powermock、jmockit等。 面向对象开发中，我们通常定义一个接口，使用一个接口来描述这个对象。在被测试代码中只是通过接口来引用对象，所以它不知道这个引用的对象是真实对象，还是mock对象。 好了，这篇文章的内容差不多就这些了，主要是让大家知道，在Java中可以使用mock对象来模拟真实对象来进行单元测试，好处很多。下一篇会详细介绍如何使用mockito框架进行单元测试。
-
单元测试第二弹——单元测试与单元测试框架 黑盒测试与白盒测试 在第一弹中我们介绍过，软件的测试包含单元测试、集成测试、系统测试和回归测试四个阶段。那么，这里我们先来看下各个阶段都使用怎样的测试方法。 软件测试，从测试方法上来区分可以分为黑盒测试、白盒测试和灰盒测试。 黑盒测试 黑盒测试，也称为功能测试。测试者不了解程序的内部情况，不需具备应用程序的代码、内部结构和编程语言的专门知识。只知道程序的输入、输出和系统的功能，这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。测试案例是依应用系统应该做的功能，照规范、规格或要求等设计。测试者选择有效输入和无效输入来验证是否正确的输出。此测试方法可适合大部分的软件测试，如集成测试以及系统测试。 黑盒测试主要是为了发现以下几类错误： 是否有不正确或遗漏的功能？ 在接口上，输入是否能正确的接受？能否输出正确的结果？ 是否有数据结构错误或外部信息（例如数据文件）访问错误？ 性能上是否能够满足要求？ 是否有初始化或终止性错误？ 白盒测试 白盒测试又称透明盒测试、结构测试等。测试应用程序的内部结构或运作，而不是测试应用程序的功能（即黑盒测试）。在白盒测试时，以编程语言的角度来设计测试案例。测试者输入数据验证数据流在程序中的流动路径，并确定适当的输出，类似测试电路中的节点。测试者了解待测试程序的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试。白盒测试可以应用于单元测试、集成测试和系统的软件测试流程。 白盒测试主要是想对程序模块进行如下检查： 对程序模块的所有独立的执行路径至少测试一遍。 对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。 在循环的边界和运行的界限内执行循环体。 测试内部数据结构的有效性，等等。 灰盒测试 灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。 对代码做白盒测试 上面介绍了软件测试中的黑盒、白盒和灰盒测试。白盒测试被广泛的使用在单元测试阶段。 这里我们先来分析下，我们要进行单元测试，需要做哪些事情？因为单元测试的主要手段是白盒测试，白盒测试的测试方法是：测试者输入数据验证数据流在程序中的流动路径，并确定适当的输出。那么整个测试流程大概需要包含以下几个步骤： 初始化测试环境、准备测试数据。 调用需要被测试的单元。 收集结果，并与期望值比较。 测试数据清理。 以上四个步骤在每个单元在被测试的时候都需要被执行。举个例子，我们有一个除法运算的方法，我们要对他做单元测试。 public class Calculator{ public float divide(float divisor，float dividend){ return divisor/dividend; } } 我们要在程序中验证上面这个方法的正确性，一般会写以下代码来测试他： public class CalculatorTest{ public static void main(String [] args){ Calculator calculator = new Calculator(); float result = calculator. divide(10.0,2.0); if(result == 5.0){ System.out.println("divide test ok"); }else{ System.out.println("divide test failed"); } } } 这只是对该方法测试的第一个测试，如果我想测试这个方法在被除数是0的情况下会怎么样，那么我就要再写一个CalculatorTest2，然后重写写一个main方法，再重新定义一个Calculator对象，然后在调用divide方法的时候把第二个参数的值传为0。 其实上面的测试是存在很大问题的，因为在内存中并无法精确的存储浮点数，当我们把两个浮点数相除的时候结果并不一定可以精确的存储下来，而我们的逾期结果却是一个精确值，这样的比较可能会不相等的。但是这样的情况需要多个case才有可能被发现。 所以，我们在测试一个类中的一个方法的时候，可能要定义大量的类，然后需要分别执行，并且通过看控制台的输出才能确认结果。 这里，请先记住这些问题，因为，接下来我们要介绍的测试框架会帮我们解决这些问题的。 单元测试框架 通常，在没有特定框架支持下，我们在对一个方法进行单元测试的时候，无外乎是使用分支判断、异常处理、流程控制等来控制代码的执行，通过程序输出来表示方法的执行成功和失败。这样存在的最大问题就是我们每执行完一个单测之后，都要去控制台看输出才知道单元测试有没有成功，这明显是不合理的，因为单元测试是需要自动化执行的，程序没办法帮我们检查输出是否正确的。 单元测试框架就解决了这个问题，一旦使用了框架，加入单元测试相对来说会简单许多。通常，Java中常用的单元测试框架一般包含三个功能：测试工具、测试套件、测试运行器。 测试工具 测试工具是一整套固定的工具用于基线测试。测试工具的目的是为了确保测试能够在共享且固定的环境中运行，因此保证测试结果的可重复性。一般负责初始化测试环境、准备测试数据和测试数据清理。 测试套件 测试套件意味捆绑几个测试案例并且同时运行。 测试运行器 用于执行测试案例。一般负责调用需要被测试的单元、收集结果、并与期望值比较。 除了以上这些功能之外，针对不同的功能，一般还会提供很多API和语法支持。 下一弹会重点介绍如何使用JUnit进行单元测试。 参考资料 白盒测试 黑盒测试 【软件测试】 黑盒测试、白盒测试、灰盒测试
-
单元测试第三弹——使用JUnit进行单元测试 上一弹中介绍了单元测试以及单元测试框架，这一弹主要来介绍一下JUnit这个目前比较流行的单测框架。 JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。 现在很多IDE中都已经集成了JUnit，当我们在创建maven项目的时候，一般在pom文件中也会自动增加junit的依赖。 junit junit test 4.4 注意上面的maven的依赖中的scope，因为junit只在测试代码中会被用到，这里scope指定未test即可。我们直接使用和介绍JUnit4。 上手JUnit 要测试，要先有被测代码（当然，基于测试编程可以先有测试代码）。先来看我们想要测试的代码： public class CaculateService { public float divide(float divisor, float dividend) { return divisor / dividend; } } 我们想要测试这个类，那么如何使用Junit进行测试呢？先来写一个测试类。如果你使用的是IntelliJ+Mac，那么可以在类名上使用快捷键option+enter直接生成测试类，这样IDE会帮忙生成一个对应的测试类。（其他操作系统和IDE也有同样的功能） 生成后的测试代码和被测代码所处路径如下： 可以看到，一般的maven项目中，会在src/main下面有两个目录，java和test，java目录中放的是源码，test目录中放的是测试代码。测试代码和测试代码的包名保持一致即可。 测试代码如下： public class CaculateServiceTest { CaculateService caculateService = new CaculateService(); @Test public void testDivide() throws Exception { Assert.assertEquals(caculateService.divide(2, 1), 2.0); } } 然后执行该方法就可以了，先不管Assert.assertEquals的用法及结果，这里总结下使用JUnit写测试代码的简单步骤： 创建一个名为 CaculateServiceTest.java 的测试类。 向测试类中添加名为 testDivide() 的方法。 向方法中添加 Annotaion @Test。 执行测试条件并且应用 Junit 的 assertEquals API 来检查。 JUnit中的Assert public class Assert extends java.lang.Object 这个类提供了一系列的编写测试的有用的声明方法。只有失败的声明方法才会被记录。 void assertEquals(boolean expected, boolean actual) 检查两个变量或者等式是否平衡 void assertFalse(boolean condition) 检查条件是假的 void assertNotNull(Object object) 检查对象不是空的 void assertNull(Object object) 检查对象是空的 void assertTrue(boolean condition) 检查条件为真 void fail() 在没有报告的情况下使测试不通过 这些方法我就不一一介绍了，相信我的读者们都能看懂并在平时开发中用的到，还是比较容易理解的。 Assert可以用来判断方法的真是结果和预期结果是否一样。是我们在写单元测试中用到最多的一个api。 JUnit中的注解 @BeforeClass：针对所有测试，只执行一次，且必须为static void @Before：初始化方法 @Test：测试方法，在这里可以测试期望异常和超时时间 @After：释放资源 @AfterClass：针对所有测试，只执行一次，且必须为static void @Ignore：忽略的测试方法 一个单元测试类执行顺序为： @BeforeClass –> @Before –> @Test –> @After –> @AfterClass 每一个测试方法的调用顺序为： @Before –> @Test –> @After 时间测试 如果一个测试用例比起指定的毫秒数花费了更多的时间，那么 Junit 将自动将它标记为失败。timeout 参数和 @Test 注释一起使用。现在让我们看看活动中的 @test(timeout)。 @Test(timeout = 1000) public void testTimeoutSuccess() { // do nothing } 异常测试 你可以测试代码是否它抛出了想要得到的异常。expected 参数和 @Test 注释一起使用。现在让我们看看活动中的 @Test(expected)。 @Test(expected = NullPointerException.class) public void testException() { throw new NullPointerException(); } 所有测试代码 代码地址 package com.hollischuang.effective.unitest.service; import org.junit.*; /** * @author Hollis 17/1/7. */ public class JUnitTest { /** * 只执行一次,在整个类执行之前执行 */ @BeforeClass public static void beforeClass() { System.out.println("in before class"); } /** * 只执行一次,在整个类执行之后执行 */ @AfterClass public static void afterClass() { System.out.println("in after class"); } /** * 每个测试方法被执行前都被执行一次 */ @Before public void before() { System.out.println("in before"); } /** * 每个测试方法被执行后都被执行一次 */ @After public void after() { System.out.println("in after"); } // test case 1 @Test public void testCase1() { System.out.println("in test case 1"); } // test case 2 @Test public void testCase2() { System.out.println("in test case 2"); } /** * 测试assertEquals */ @Test public void testEquals() { Assert.assertEquals(1 + 2, 3); } /** * 测试assertTrue */ @Test public void testTrue() { Assert.assertTrue(1 + 2 == 3); } /** * 测试assertFalse */ @Test public void testFals() { Assert.assertFalse(1 + 2 == 4); } /** * 测试assertNotNull */ @Test public void assertNotNull() { Assert.assertNotNull("not null"); } /** * 测试assertNull */ @Test public void assertNull() { Assert.assertNull(null); } /** * 测试fail和Ignore */ @Test @Ignore public void assertFail() { Assert.fail(); } /** * 测试异常 */ @Test(expected = NullPointerException.class) public void testException() { throw new NullPointerException(); } /** * 测试时间 */ @Test(timeout = 1000) public void testTimeoutSuccess() { // do nothing } /** * 测试时间 */ @Test(timeout = 1000) public void testTimeoutFailed() { while (true) { } } } 总结 本文主要介绍了JUnit的常见用法，后面会专门写一篇文章介绍如何将JUnit和Spring集合到一起。
-
单元测试第一弹——从软件开发生命周期谈单元测试 关于单元测试的重要性，本文不再赘述了。相信很多人都知道单测的重要性。但是在日常工作中写单测的人很少。很多项目的单测覆盖率和通过率一般都很低，尤其是web项目。 本文从软件开发的生命周期开始谈起，让我们站在一个全局的角度来看一下单元测试到底扮演着怎样的角色。 软件开发生命周期 一个软件或者系统，从开发到上线基本要经过以下三个步骤：持续集成、持续交付、持续部署。在The Product Managers’ Guide to Continuous Delivery and DevOps一文中详细介绍了这三个阶段。 持续集成 持续集成(Continuous Integration)是指在软件开发过程中，频繁地将代码集成到主干上，然后进行自动化测试。 我们集团内部有持续集成的平台，可以直接在上面运行自动化测试。其实如果没有这样的平台，开发人员也可以做持续集成。 其实持续集成就是git commit + mvn clean install。注意，这里的maven命令不要加-Dtest.skip 持续交付 持续交付(Continuous Delivery)是指在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的“类生产环境”（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中进行更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。 这一步是在上线前的最后一次测试了，是在一个和生成环境一样的环境中进行测试。 持续部署 持续部署(Continuous Deploy)是在持续交付的基础上，把部署到生产环境的过程自动化。持续部署和持续交付的区别就是最终部署到生产环境是自动化的。 上面这三个阶段，都提到了一个词，那就是自动化测试。 自动化指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。 软件测试 现在我们知道，一个软件的从无到有或者每一次迭代都需要通过持续集成、持续交付、持续部署三个阶段。而每一个阶段都伴随着自动化测试，这足以看出测试的重要性。既然提到自动化的软件测试，那么我就要搞清楚到底什么是软件测试。 软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。 目前，被普遍认可的软件测试包括以下几个阶段： 单元测试 单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：函数。 集成测试 集成测试也称综合测试、组装测试、联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。 系统测试 系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。 回归测试 回归测试指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。 在整个软件测试的生命周期中，以单元测试开始，然后依次是集成测试、系统测试、回归测试。 软件测试的四个阶段，无论是复杂性还是成本，都是依次递增的。这个其实很好理解，当我们测试一个函数的时候发现问题简单，还是做整个功能的演示的时候发现问题简单？当我们在测试函数的时候发现问题好修改还是做功能演示的时候发现问题好修改？答案，不言而喻。 单元测试 至此，我们知道，整个软件的上线过程中，都要进行自动化的软件测试。而软件测试主要有四个阶段：单元测试、集成测试、系统测试、回归测试。 那么，单元测试作为测试的第一个阶段，是发现和解决问题需要付出的成本最小的。那么，到底什么是单元测试？ 单元测试（英语：Unit Testing）又称为模块测试, 是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。 其实，可以很简单的说，就是我们在写代码的时候，对我们写出来的每一个重要的方法进行测试。 本文暂时不打算对单元测试涉及到的技术做详细介绍。后面我会有文章分专题的介绍单元测试涉及到的技术。目前我能想到的可能涉及到主要技术及知识点主要有以下这些： 什么地方改写单测 单元测试框架 spring与单测框架的融合 数据库的单元测试 服务的mock测试 覆盖率 测试类及方法的命名 单测编写规范 这个专题我会持续做完，欢迎持续关注，同时也欢迎补充~ 总结 单元测试贯穿整个软件开发的声明周期，无论哪个阶段都离不开单元测试。单元测试就是对程序的模块最测试。在面向对象编程中，主要是对函数的测试。单测涉及到的知识和技术比较多，本文暂时不做详细介绍。后面会逐一分析。 参考资料 单元测试 软件测试
