# UnitTestExample

**Repository Path**: chenjinku/UnitTestExample

## Basic Information

- **Project Name**: UnitTestExample
- **Description**: 单元测试：TDD，Junit、Hamcrest、Mockito、测试覆盖率等相关例子。
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 13
- **Created**: 2021-06-08
- **Last Updated**: 2021-06-08

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

### 概述

#### 测试的种类，什么是单元测试
- 单元测试：测试单个类的行为
- 集成测试：测试多个类组合的行为
- 功能测试：从用例、用户故事的角度测试系统
- 压力测试：测试系统的并发和吞吐量
- 验收测试：站在用户的角度全面测试、包括功能性、易用性质

#### 现状
- 不知道怎么编写单元测试
- 项目没有要求，所以不编写
- 单元测试价值不高，完全是浪费时间
- 业务逻辑比较简单，不值得编写单元测试
- 集成测试将会抓住所有的 bug，用不着进行单元测试
- 为了完成编码任务，没有足够的时间编写单元测试。

#### 正确对待单元测试
- 观念更新比技术更重要
- 单元测试不会增加开发成本，而只会降低成本
- 没有经过测试或者不可测试的代码不可信赖
- 一个bug被隐藏的时间越长，修复这个bug的代价就越大（技术债务）

#### 单元测试的好处
- 单元测试可以减少调试时间，提高bug定位速度
- 单元测试让开发人员在重构、依赖版本升级、业务调整等情况发生时更加自信
- 单元测试能够更好的把握需求，测试即文档
- 覆盖测试能发现潜在的风险

#### 单元测试方法论
- TDD：测试驱动开发（Test-Driven Development）
  
   TDD的基本思路就是通过测试来推动整个开发的进行。测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发
 - ATDD：验收测试驱动开发（Acceptance Test Driven Development）
 
TDD只涉及到Developer（开发者），只能算个人工作方式的改变。而ATDD提倡整个团队（产品经理、测试人员（或QA）、开发人员）在开发工作开始之前，一起讨论、制定每个任务（或者用户故事）的验收标准，并提取出一组验收测试用例。
 - BDD：行为驱动开发（Behavior Driven Development）
   BDD的核心价值是体现在正确的对系统行为进行设计，所以它并非一种行之有效的测试方法。它强调的是系统最终的实现与用户期望的行为是一致的、验证代码实现是否符合设计目标。
 - specification by example：实例化需求
 
#### 单元测试原则
- 快速：耗时的外部环境（db、网络、第三方接口）全部通过mock实现 
- 自动化：自动化执行，无需手动干预
- 及时回归:针对每次变更和提交都需要重新运行