在项目中进行测试

单元测试

1. 把测试代码放到哪？

• 同一目录： 组织测试代码最优先也是最简单的方法是把测试简单地包含在同一目录中，紧挨着产品代码。
• 子目录： 在产品代码的目录下创建一个test子目录
• 并行树： 测试代码放入和你的产品代码的同一个包中，但应该位于不同的源代码树。

选中一种看上去适合你所处环境的风格，并且在系统中的所有单元测试中坚持这种风格。

2. 测试的礼貌

所有的测试应该在任何时刻都能通过

不能push的垃圾代码：

1. 不完整的代码
2. 不能编译的代码
3. 代码能编译，但是会破坏已经存在的代码
4. 没有相应单元测试的代码
5. 不能通过单元测试的代码
6. 通过了自己的测试，但是导致系统其他地方的其他测试失败的代码

3. 测试的频率

1. 编写新的函数，编译并运行本地单元测试
2. 修正bug，运行测试找寻bug，修正并再次运行单元测试
3. 每次成功编译后，运行单元测试
4. 每次对版本控制的签入，运行所有的模块或系统的单元测试
5. 持续不断的。应当有一台专门的机器来运行完整的构建和测试（要么时周期性，要么时每次版本控制签入时）

4. 测试和遗留代码

如何对没有进行过单元测试的遗留代码添加单元测试？
- 如果它是合理的，重构充分的以及模块化的，那么你可以获得所有你需要的独立部分，然后容易的添加单元测试。
- 如果那是一团糟，所有的东西纠缠在一起，那么就不得不重写一些代码再进行单元测试。

对于新写的代码你显然应该同时编写单元测试。
对于已经存在的代码，你可以选择为可测试的一切代码系统地添加单元测试。最好是只给最有可能出问题的代码添加测试。

5. 测试与评审

无论是否进行代码评审，都要让测试代码成为评审过程的一个组成部分。

测试先于设计的思想：在编写产品代码之前，同时编写和评审测试。
1. 编写 test case 和/或测试代码
2. 评审 test case 和/或测试代码
3. 经评审修改 test case 和/或测试代码
4. 编写能通过所有测试的产品代码
5. 评审产品代码和测试代码
6. 每次评审后，修改测试代码和产品代码