what's unit test, why uni test, how to write unit test

1. 1
Sam Chen
软件开发单元测试

2. 为什么需要单元测试？
— 软件不停在迭代.
— 需求改变.
— 发现Bug.
— 优化.
— 重构.
— 软件是脆弱的.
— 新的改动有可能破坏老的功能.
— 新的改动不能引入新的问题.
— 人工测试永远无法做到完美.
2

3. 测试种类
— 系统集成测试
— 压力测试
— 单步调试测试 - 程序猿
— 接收测试
— 回归测试
— 单元测试 - 程序猿
3

4. 大多数的工程师测试就像
4

5. 什么是单元测试
— 小测试 (面向函数).
— 很快（机器执行）.
— 很便捷 (自动化).
— 程序猿写的.
— 好部署
— 可重复执行的.
— 可靠的.
5

6. 为什么要单元测试？
— 每个程序猿都会犯错，只有单元测试能够第一时间发现
你的错误。.
— 只有单元测试才能保证所有的边界条件都被测到.
— 可测试的代码，往往意味着好的设计。
— 从使用方角度去考虑往往能设计出好的接口。
— 单元测试需要减少依赖，这本身就是设计的要求之一。
— 单元测试能让你在解决bug或重构代码的时候更有信心。
— 单元测试代码就是最好的文档。
— 单元测试可以用来辅助调试。
6

7. 对单元测试说‘不’？
— 我没有时间.
— 如果你之前写了单元测试，现在你就不会这么忙了.
— 我的代码太复杂，不能写单元测试.
— 是时间Review一下你的代码了.
— 我的模块已经运行了好多年，非常稳定.
— 恭喜你，非常好的设计。但你能保证你接下来不需要重构你的代
码，不担心新的改动会破坏已有的功能？
— 我们是嵌入式开发，需要硬件配合，无法做单元测试.
— 好理由，但事实上通过Mock是可以做到的.
— 等我东西发布有时间后我再做单元测试.
— 太迟了，因为那个时间，你测试的是你的实现，而不是你的设计
7

8. 多少单元测试是合理的
— 准则： 当你可以放心的让一个实习生来修改你的代码，而
不用担心它的提交会破坏已有的行为，这个单元测试就
足够了
8

9. 测试驱动开发（TDD)
9

10. 什么是TDD
— Test-Driven Design (Development)
— 在写功能代码之前写单元测试.
— 只写能够通过测试的代码。
— 添加新的代码或重构，重复执行第一步.
10

11. 好处和坏处
— 好处
— 所有代码都被测试保护.
— Bug会变少，解bug时间也相应小.
— 写测试会带来好的设计.
— 测试结果可以告诉你当前的进度
— 需要少的测试人员。
— ⻓长远看，单元测试的成本是非常低的
— Cons
— 测试代码需要工程师编写和维护.
— 初期，会减慢开发进度
— 执行困难，久了会产生疲倦。
11

12. 改进的 TDD
— 关键是在写功能代码前写测试代码.
— 对关键部分写足够的代码
— 结对编程。
12

13. 写单元测试和可测试的代
码
13

14. 嵌入式系统中的单元测试难点
— 依赖对象
— 慢的依赖对象，如播放一个视频
— 易变的依赖，如不同的视频内容
— 依赖对象的准备，播放视频前需要加载.
— 单元测试的部署.
— 嵌入式软件一般只能跑在硬件上。
14

15. 写可测试的代码1-简单的函数.
15

16. 写可测试的代码 –隔离依赖.
— X 依赖 Y 如果
— X调用Y.
— X 继承Y.
— X 依赖Y，而Y依赖Z (依赖迁移).
— X: Dependant
— Y: Component or Service.
16

17. 如何解除依赖？
17

18. 写可承受的代码(3) – 可重入
— 可重⼊入代码⼀一般
— 不使用全局或静态变量.
— 不调用不可重入的接口.
18

19. 写可测试代码-避免不用的头文
件
19

20. SOLID Design Principles
— S Single Responsibility Principle
— O Open Closed Principle
— L Liskov Substitution Principle
— I Interface Segregation Principle
— D Dependency Inversion Principle
20

21. OO princibles
— 封装变化的部分。
— 组合优于继承。
— 针对接口而不是实现编程。
— 对修改封闭，对扩展开放.
— 依赖抽象类，而不是具体的实现.
— .
21

22. 设计模式
— Design pattern are try-and-trust programming patterns.
— Strategy
— Factory
— State
— Observer
— Proxy
— Adaptor
— MVC (Modal-View-Controller)
— DI (Dependency Injection)
— An example of using Design patterns to refactor baseband
player.
22

23. GTest
— http://code.google.com/p/googletest/
— What is
— A library for writing C++ tests
— Open-source with new BSD license
— Based on xUnit architecture
— Supports Android, Linux, Windows, Mac OS, and other Oses
— Can generate JUnit-style XML, parsable by Hudson or Jenkins.
— Features
— Add debug info to assertions using <<
— Death tests
— User-defined predicate assertions
— Value/type-parameterized tests
— Test event listener API (user-defined plug-ins)
— Test filtering
— Test shuffling
23

24. Gmock
— Gmock (Google C++ Mocking Framework) is a library for writing and
using C++ mock classes.
— create mock classes trivially using simple macros.
— supports a rich set of matchers and actions.
— handles unordered, partially ordered, or completely ordered expectations
— Gmock is not a test framework, it works seamless with Gtest.
— http://code.google.com/p/googlemock/
24

25. Gmock Example
25

26. 单元测试框架
26

27. Reference.
— http://code.google.com/p/googletest/
— http://code.google.com/p/googlemock/
— http://martinfowler.com/articles/injection.html
— Test Driven Development for Embedded C by James W. Grenning
— Head first Desgin Patterns, O-Reilly by Eric Freeman.
— Pragmatic programmers - pragmatic unit testing (in java with junit) –
2003 - by laxxuss
— http://targetprocess.com
27