测试驱动编程(2)进阶单元测试（上）

单元测试

要打造出出类拔萃的作品，你必须专注于最小的细节

单元测试正确打开方式

• 单元测试应该是测试流程中占比最重的部分
• 单元测试通常来说是指方法，但是有些情况下，整个类乃至整个应用程序都可视为单元
• 单元测试是为了缩小其它（功能，集成）测试的范围，如果一个组织主要依赖于手动测试，这本身就是有问题的
• 单元测试编写更容易，也能让代码的问题尽早暴露
• 单元测试为代码重构提供了有力的支持

各类测试比较

下图测试金字塔展示的是UI测试、集成测试、单元测试之间的比重，单元测试要比其它测试多得多

拿最常见的用户注册测试场景举例，最常看到的测试用例就是要考虑用户名为空、密码为空、用户名格式、密码格式、用户名是否存在、密码安全等级等等。

仅为测试这一项功能，就可能需要数十个测试，再加上边界值等情况可能导致上百个测试用例，如果是人工的UI测试，那么代价将是非常大的。

如果使用单元测试来做这些会简单和方便的多，人工只需要填写一个集成测试，检查是否调用了正确的后端方法即可，而无需关注细节。当注册逻辑发生改变了也没关系，因为新单元测试会自动进行测试。

TDD中的单元测试

TDD中的单元测试和传统的单元测试有什么不同呢？答案是：时机
看过我之前写的一篇文章，测试驱动编程快速入门的应该都知道了一个名字：红绿重构

传统先写业务再写单元测试，主要是为了验证业务代码写的对不对，而TDD中的单元测试主要目标是作为驱动开发和设计的动力，定义了我们应该做什么以及做到什么程度，验证只是副产品。

完成的工作量和具体的测试(单元、功能、集成)有关，TDD中的单元测试制订接下来完成尽可能小的任务，要求我们遵循一些设计原则(KISS、SOLID)，确保代码的可测试性和解耦性。

TDD迫使我们详细地考虑需求和设计，编写整洁而可行的代码，以及创建可执行的需求并频繁重构。