junit单元测试

在测试restful风格的接口时，springmvc为我们提供了MockMVC架构，使用起来也很方便。 下面写个笔记，便于以后使用时参考备用。 一 场景 1 . 提供一个restful风格的接口 import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; import qinfeng.zheng.mockmvcdemo.dto.User; import java.util.ArrayList; import java.util.List; @RestController public class UserController { @GetMapping("/users") public List<User> getUserList() { List<User> users = new ArrayList<>(); users.add(new User()); users.add(new User()); return users; } } @Data public class User { private String username; private String password; } 2.

一、单元测试的目的？ 单元测试是编写测试代码，用以检测特定的、明确的、细颗粒的功能! 严格来说，单元测试只针对功能点进行测试，不包括对业务流程正确性的测试。现在一般公司都会进行业务流程的测试,这也要求测试人员需要了解需求! 测试人员也不好过啊~~ 目前开发所用的单元是Junit框架，在大多数java的开发环境中已经集成，可以方便开发自己调用! 注意：单元测试不仅仅是要保证代码的正确性，一份好的单元测试报告，还要完整地记录问题的所在和缺陷以及正确的状态，方便后面代码的修复，重构和改进! 二、单元测试做什么？ 一般来说，一份单元测试主要包括以下几个方面： ============================================================================================== 1.接口功能性测试: 接口功能的正确性,即保证接口能够被正常调用，并输出有效数据! ------------------> 是否被顺利调用 ------------------> 参数是否符合预期 ============================================================================================== 2.局部数据结构测试：保证数据结构的正确性 ----------

1. 为什么做单测 单测的好处 减少bug 快速定位bug 提高代码质量 减少调试时间 放心重构 不得不写单测的原因 在成为大牛的路上，单测是必备技能 单测可以给你信心 保住面子 难处 难于坚持,在快速迭代开发过程中，可供写单测的时间过少 扩展 TDD（Test Drive Develop）：测试驱动开发，是一种非常高效的开发方式 2. 测试框架 2.1 概述 junit4.12 （单测框架） mockito1.9.5（mock工具） robolectric3.1.2 （模拟Android虚拟机） 2.2 junit4.12 Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。 示例代码： @Before: 执行单测之前的初始化操作。 @After：单测完成后收尾工作。 @Before public void setUp() throws Exception { } @After public void tearDown() throws Exception { } assume: 用于判断测试用例的入参是否有业务含义的工具，如果入参不符合预期时会抛出 assumptionViolatedException、assumeTrue

什么是单元测试？如何做好单元测试？ 单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。 单元测试都是以自动化的方式执行，所以在大量回归测试的场景下更能带来高收益。 单元测试代码里提供函数的使用示例，因为单元测试的具体表现形式就是对函数以各种不同输入参数组合进行调用。 如何做好单元测试？ 1）代码的基本特征与产生错误的原因 无论是开发语言还是脚本语言，都会有条件分支、循环处理和函数调用等最基本的逻辑控制，如果抛开代码需要实现的具体业务逻辑，仅看代码结构的话，所有的代码都是在对数据进行分类处理，每一次条件判定都是一次分类处理，嵌套的条件判定或者循环执行，也是在做分类处理。 如果有任何一个分类遗漏，都会产生缺陷；如果有任何一个分类错误，也会产生缺陷；如果分类正确也没有遗漏，但是分类时的处理逻辑错误，也会产生缺陷。 2）单元测试用例详解 单元测试的用例是一个“输入数据”和“预计输出”的集合。需要针对确定的输入，根据逻辑功能推算出预期正确的输出，并且以执行被测试代码的方式进行验证。即“在明确了代码需要实现的逻辑功能的基础上，什么输入，应该产生什么输出”。 单元测试用例“输入数据”种类： 被测试函数的输入参数； 被测试函数内部需要读取的全局静态变量； 被测试函数内部需要读取的成员变量； 函数内部调用子函数获得的数据

学习如何使用本教程中提供的工具，并在 Spring Boot 环境中编写单元测试和集成测试。 1. 概览 本文中，我们将了解如何编写单元测试并将其集成在 Spring Boot 环境中。你可在网上找到大量关于这个主题的教程，但很难在一个页面中找到你需要的所有信息。我经常注意到初级开发人员混淆了单元测试和集成测试的概念，特别是在谈到 Spring 生态系统时。我将尝试讲清楚不同注解在不同上下文中的用法。 2. 单元测试 vs. 集成测试 维基百科是这么说 单元测试 的： 在计算机编程中，单元测试是一种软件测试方法，用以测试源代码的单个单元、一个或多个计算机程序模块的集合以及相关的控制数据、使用过程和操作过程，以确定它们是否适合使用。 集成测试 ： “集成测试（有时也称集成和测试，缩写为 I&T）是软件测试的一个阶段，在这个阶段中，各个软件模块被组合在一起来进行测试。” 简而言之，当我们在做单元测试时，只是测试了一个代码单元，每次只测试一个方法，不包括与正测试组件相交互的其他所有组件。 另一方面，在集成测试中，我们测试各组件之间的集成。 由于单元测试，我们可知这些组件行为与所需一致，但不清楚它们是如何在一起工作的。 这就是集成测试的职责。 3. Java 单元测试 所有 Java 开发者都知道 JUnit 是执行单元测试的主要框架。它提供了许多注解来对期望进行断言。 Hamcrest

在Junit单元测试中，经常需要对一些领域模型的属性赋值，以便传递给业务类测试，常见的场景如下： com.enation.javashop.Goods goods = new com.enation.javashop.Goods(); goods.setBrandId(1); goods.setCategoryId(1); goods.setGoodsName("测试商品"); goods.setPrice(1.01); goods.setSn("100001"); goods.setWeight(1.01); 　　 如果领域模型的属性特别多，手工去写set方法令人发指，写了一个生成的工具类，用法如下： String mockCode = MockDataGenerator.create(Goods.class); 　 生成结果： com.enation.javashop.Goods goods = new com.enation.javashop.Goods(); goods.setBrandId(819); goods.setCategoryId(109); goods.setCost(1.01); goods.setGoodsId(970); goods.setGoodsName("random_str748"); goods.setGoodsTransfeeCharge

Agile-单元测试 单元测试 (Unit testing) 待单元程序(unit, 如一个 Java public method source code) 完成后，用工具(如JUnit)，自动执行 test code，测试该单元 (unit) 叫单元测试 逆向工程 工具 利用逆向工程 工具 如 BOUML *需要时，可由程序(source file；不含 reused code) 动态产生 class diagram, sequence diagram 等文档，供了解软件全貌、决定维修那个class及检查相关classes(为了解软件全貌，main program 之前也要有标头:系统描述、重大决策)这有可能敏捷达成 CMMI 一些 process areas 的 goals VS是有相关的软体可用，只是不知道那个最顺手~~~ p.s 写到这里算是把Agile大概走一遍，接下来有实做心得再记录了~~~ 自我LV~ 原文: 大专栏 Agile-单元测试 来源： https://www.cnblogs.com/chinatrump/p/11516249.html

一、概述 软件测试是程序的一种执行过程，目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。 二、测试分类 1、按照是否知道源代码 黑盒测试：不关心具体的逻辑代码，只测功能 白盒测试：测试逻辑代码 灰盒测试：介于黑盒和白盒之间 2、从软件开发的过程 单元测试：Unit Testing 集成测试：Integrated Testing 系统测试：System Testing 3、根据测试的次数 冒烟测试 压力测试 三、Junit单元测试 Junit是一个基于Java语言的单元测试框架。是白盒测试的一种技术。 1、注意事项【重点】 测试方法上必须使用@Test进行修饰 测试方法必须使用public void 进行修饰，不能带任何的参数 新建一个源代码目录来存放我们的测试代码，即将测试代码和项目业务代码分开 测试类所在的包名应该和被测试类所在的包名保持一致，末尾【.test】 测试单元中的每个方法必须可以独立测试，测试方法间不能有任何的依赖 测试类使用Test作为类名的后缀（不是必须） 测试方法使用test作为方法名的前缀（不是必须） 2、一般测试TEST注解 public class UserDaoTest { @Test public void testAdd ( ) { UserDao userDao = new UserDao ( ) ; User user = new

对于一些有经验的开发觉得写单元测试是非常有必要的，也仅仅是觉得，可能写的不是太多，但是一些新手代码都写不顺的让他们再去写单元测试，估计他们的内心是相当崩溃的，但是单元测试时真的有必要，而且对自己的代码质量以及编码能力都是有提高的。 一、什么是单元测试？ 单元测试是针对程序的最小单元来进行正确性检验的测试工作，程序单元就是应用的最小可测试部件，一个单元可能是单个程序，类，对象，方法等。 二、使用单元测试有什么好处？ 1.减少bug 通过运行单元测试可以直接测试各个功能的正确性，有bug可以直接发现并解决，如果要等到跟其他的功能对接，进行连贯测试，测试比较麻烦，而且bug不能及早的发现并解决 2.快速定位bug 如果是web项目的某一个功能，平常我们定位bug可能是页面输入值，后台断点，一步一步的需要bug位置，如果有编写单元测试，则可以直接修改数据，运行单元测试即可，快速有限 3.提高代码质量 如果每一个部件都是完美的，那么组合起来肯定也是完美的。整体代码质量就得到了保障 4.减少调试时间 当不知问题所在的时候，可能需要各种调试与运行，而如果所有的都有编写单元测试，那么可以直接运行单元测试，就能定位问题所在位置。 三、单元测试的一些注意事项 测试方法必须使用@Test修饰 测试方法必须使用public void进行修饰，不能带参数 测试代码的包应该和被测试的代码包结构保持一致

一、如果我们遇到下面情况，就需要单元测试（框架）： 测试代码没有很好地维护而废弃，再次需要测试时还需要重写； 投入太多的精力，找 bug，而新的代码仍然会出现类似 bug； 写完代码，心里没底，是否有大量 bug 等待自己； 新修改的代码不知道是否影响其他部分代码； 由于牵扯太多，导致不敢进行修改代码； …… 二、C++单元测试工具选择 从 Java 的 JUnit 移植出 CppUnit 之后，又出现了一系列的 CppUnit 的衍生套件， 但是易用性都不太好，且有一些“顽疾”，最终都被作者遗弃了，停止了维护更新。 相对而言，出现较晚的 xUnit 衍生品 googletest 有诸多优点： 不需要再像以前那样进行麻烦的声明、定义以及注册了，一切就像调用函数那么简单； 适用诸多平台 (Linux, Mac OS X, Windows, Cygwin, Windows CE, and Symbian)； 更多功能、更加可定制化； 显示信息更加丰富全面 …… 参考资料： 便利的开发工具 CppUnit 快速使用指南 ； C/C++单元测试框架的选择(CppUTest vs. CppUnit vs. CppUnitLite vs. CppTest vs. GoogleTest vs. CxxTest vs. CUnit) ； Google 开源了自己的 C++ 单元测试框架 ：