单元测试

断言方法 检查条件 assertEqual(a, b) a == b assertNotEqual(a, b) a != b assertTrue(x) bool(x) is True assertFalse(x) bool(x) is False assertIs(a, b) a is b assertIsNot(a, b) a is not b assertIsNone(x) x is None assertIsNotNone(x) x is not None assertIn(a, b) a in b assertNotIn(a, b) a not in b assertlsInstance(a, b) isinstance(a, b) assertNotIsInstance(a, b) not isinstance(a, b) 来源： https://www.cnblogs.com/chenminyu/p/11724037.html

from testcase1 import countimport unittestclass MyTest(unittest.TestCase): def setUp(self): print('test start') def tearDown(self): print('test end')class TestCount(unittest.TestCase): def test_add(self): j=count(3,2) self.assertEqual(j.add(),5) def test_add2(self): j=count(3,4) self.assertEqual(j.add(),7)if __name__ == '__main__': # unittest.main() #构造测试集 单个案例 suite=unittest.TestSuite() suite.addTest(TestCount('test_add2')) #执行测试集 runner=unittest.TextTestRunner() runner.run() 来源： https://www.cnblogs.com/panpan8554/p/11724055.html

在测试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.

Xctest 是iOS的单元测试框架，有objective-c和swift两种语言可以选择 Xcuitest 是iOS的UI测试框架 XCTest 官方文档地址： https://developer.apple.com/documentation/xctest XCTest 框架类似于python中的unit test框架，声明一个测试case继承XCTestCase和测试方法，测试方法以test开头，然后执行。 相关类介绍： Class XCTest XCTest类提供XCTestCase和XCTestSuite用于创建、管理和执行测试的共享功能。在大多数情况下，在项目中定义测试时，应该直接子类化XCTestCase。 包含了以下属性： name: test 的 name testCaseCount: case个数 testRun: XCTestRun对象来执行test testRunClass: 运行测试时实例化的XCTestRun子类，以保存测试结果。 包含了以下方法： perform( XCTestRun ): 执行一个特定的测试 run（）：创建testRunClass指定的类的实例，并将其作为参数传递给执行perform(_:)方法。 还包含了一系列的断言方法 Class XCTestCase 具体的属性和方法看文档，主要包含代码块性能检测，异步测试（例如打开文档

为什么要做单元测试 通常我们在做任何工作会先考虑它的回报，编写代码更是如此。如果单元测试的作用不大，没有人会愿意再写一堆无用的代码，那么单元测试到底能够给我们带来什么优点呢？如下： 便于后期重构。单元测试可以为代码的重构提供保障，只要重构代码之后单元测试全部运行通过，那么在很大程度上表示这次重构没有引入新的BUG，当然这是建立在完整、有效的单元测试覆盖率的基础上。 优化设计。编写单元测试将使用户从调用者的角度观察、思考，特别是使用TDD驱动开发的开发方式，会让使用者把程序设计成易于调用和可测试，并且解除软件中的耦合。 文档记录。单元测试就是一种无价的文档，它是展示函数或类如何使用的最佳文档，这份文档是可编译、可运行的、并且它保持最新，永远与代码同步。 具有回归性。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地地快速运行测试，而不是将代码部署到设备之后，然后再手动地覆盖各种执行路径，这样的行为效率低下，浪费时间。 等等，讲了这么多优点，无非就是良好的接口设计、正确性、可回归、可测试、完善的调用文档、高内聚、低耦合，这些优点已经足以让我们对单元测试重视起来了，但是个人觉得还有更重要的原因。 首先，带来自信。在接手一个新的项目，或者说是参与一个新的项目开发时，往往这种情况是你半途参加进去的，你需要对已有的代码结构进行解读和理解，对于业务的理解

迷思1：单元测试使得更改变得更加困难 事实却是相反的。进行单元测试的最大优点之一就是能够对代码进行大型修改，然后立即对所做更改进行正确性测试。进行代码修改，后来蔡意识到软件的其他部分受到了影响，接下来试图隔离出引起问题的代码，这不单单使得代码的更改更加困难，也让开发人员恐惧更改代码。 事实是：单元测试使得代码更改更加容易，而且也让开发人员毫无顾虑地修改代码。一遍，两遍等等。能对代码修改是人们选择进行单元测试的最大的理由之一。 迷思2 :单元测试减慢了开发过程 进行单元测试一开始会让开发过程慢一点，然而事实是这么做反而节省了时间：它在开发过程继续进行之前就防止了错误，并识别出错误出现的地方。而 且 单元测试也使得开发人员对自己已经完成的工作更加有信心，这样就会扫清开发过程中出现的障碍。纵观整个开发过程，进行单元测试最终会使得总体花费时间 会更 短。 事实是：像任何一种新工具一样，习惯进行单元测试也需要一点时间，不过，总的来说，进行单元测试可以节省时间，同时浪费的时间也会缩短。实际 上， 进行回归测试可以持续不断地推进开发过程，并且不会有任何担心。假若在日常构建时进行单元测试，那么这样的测试是不会占用开发时间的。 迷思3：单元测试让开发人员远离代码 这是很显然的误解。正是开发人员才能帮助设计测试程序。这就意味着开发人员需要更加深入的了解代码功能

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

第二次结对编程作业 一、题目描述 题目：“福建赌王”之争 【题目背景】     话说，自称“赌王”的老周与同样自称“赌王”的老刘在福州展开“赌王”名号的争夺。两人商议决定使用福建当地的一套纸牌游戏规则进行博弈，即“福建十三水”。约定三周后展开决战。老刘修习代码多年，希望开发一套自动化的出牌系统，具体游戏规则请上网查询或找福大柯老板，本次作业要求提交一份完整的前端后端代码。 WARNING：珍惜钱财，远离赌博（含AI赌博）。 二、相关的链接 我的Github地址 详情 结对同学的博客链接 详情 上次原型设计的博客链接 详情 三、具体的分工     这次的分工由周鑫煌负责前端代码的编写(制作出一款简易的App),由我进行后端代码与算法的编写(使用java语言). 四、PSP表格 PSP2.2 Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟） Planning 计划 300 320 Estimate 估计这个任务需要多少时间 60 70 Development 开发 650 850 Analysis 需求分析(包括学习新技术) 240 300 Design Spec 生成设计文档 30 30 Design Review 设计复审 30 40 Coding Standard 代码规范(为开发制定合适的规范) 60 60 Design

最近做研发质量分析，大家共同提到了一个改进措施： 加强开发自测！ 但是如何加强开发自测、怎么做好开发自测？带着这个问题，进入我们今天的分享： 一、开发测试小记 开发同学功能开发完成后，简单自测通过后，填写提交单提交测试，然后： 制作的补丁，打到测试环境，发现丢了一些SQL、Dll、配置，然后提交单被测试无情地打回。 即便补丁更新成功，扛不住测试用例的第一轮饱和测试，出现影响测试进展的Bug，或者Bug太多，满足打回标准，提交单继续被无情打回。 提交单打回后，开发同学集中修复了Bug，再次提交测试。正常情况下，第二轮功能测试发现的Bug会大幅减少，如果重新提交的补丁质量不佳，修复Bug的同时，带来了更多新的Bug，提交单还是有可能继续被打回。 功能测试通过后，进行性能测试，并发压力上来后，功能被打爆、数据库被打爆、MQ被打爆，提交单再次被打回。 …… 上面的场景，大家都很熟悉，很多开发、测试同学通过都经历过。我们如何用真正的行动来加强开发自测，提升交付质量？ 我们需要有一套开发自测方法论： 二、开发自测方法论 我们详细展开讲一下： 1. 思想意识上，提升对自测的重视程度 开发阶段不仅是代码开发完成，编译通过，更重要的是自测通过。 自测工作投入应该占开发阶段整体投入的30%，如果保证不了资源投入，自测只是一个形式； 自测工作必须覆盖全面的自测场景：正向、逆向、正常、异常、并发性能等等；

背景动机 某期优化需要针对通用的HttpClient封装组件--HttpExecutor在保证上层暴露API不动的前提做较多改动，大致包括以下几点： apache http client 版本升级 HttpClientBuilder代码重构 RequestBuilder代码重构 自定义RetryHandler HttpContext扩展 自定义HttpRequestInterceptor/HttpResponseInterceptor 代码很快修改完了，但是如何保证HttpExecutor的行为和以前是一致的呢？很容易就想到是单元测试。因为以前的代码并未提供组件的单元测试，都是依赖QA同学的黑盒测试完成，现有的单元测试又都是在更上层的HttpDao上，重点是对返回数据的解析逻辑代码验证，直接Mock了HttpExecutor的返回结果，完全无法覆盖底层组件的请求逻辑，因此配合本期优化需要提供HttpExecutor组件的单元测试。 需求分析 先大致分析一下HttpExecutor组件提供的功能： 注册apache http client实例的初始化和销毁，包含ConnectionManager等apache http client子功能组件； 上层入参的转封装，以及HttpResponse结果的初步解析封装（response header、status code、response