TDD和单元测试

Test Driven Development。测试驱动开发，提倡在开发足够多的代码之前优先写单元测试，然后重构开发者编写的源代码。初学者会问，源代码都没有怎么写单元测试？请注意是开发足够多的代码之前，也就是会有少量源代码工作在单元测试之前，如功能模块骨架，方法定义、类依赖。

三个准则：

1. 定律一、在编写不能通过的单元测试前，不可编写生产代码。(写生产代码前，先写针对其需求的单元测试，当然因为生产代码还没写，这个单元测试肯定是失败、无法通过)
2. 定律二、只可编写刚好无法通过的单元测试，不能编译也算不过。(测试小步走，写一个单元测试不要一下子写太多测试功能，如编译不通过，如果生产代码还没写，那单元测试代码肯定编译不通过，这就够了)
3. 定律三、只可编写刚好足以通过当前失败测试的生产代码。（生产代码小步走，生产代码要基于测试代码，先写测试代码再写生产代码，测试失败什么、生产代码才能写什么，）

测试代码要求：和生产代码一样重要，必须规范、必须有可读性。

TDD 生命周期。(遵守这六个步骤)

1. 编写测试。（首次写一个测试类，此时没有写生产类，导致编译失败，再去创建生产类，就能编译通过）（或写其他逻辑条件的测试用例）
2. 运行测试（生产类没有实现代码，测试不通过）
3. 编写足够的实现代码以使测试通过(实现生产类，关注于实现功能)
4. 运行所有测试（每次对类修改， 都要进行测试，测试不通过就回到步骤3）
5. 重构(不断疯狂重构，每次重构运行单元测试，测试不通过就回到步骤3，重构可能会产生新类、新方法，如果有必要也应该增加单元测试)
6. 重复（重复整个流程，直到所有测试条件都能通过，并且覆盖所有代码的逻辑分支、如ifelse分支）

以上6步是详细步骤，此外有名的 “TDD 红-绿-重构”是对步骤的总结。

单元测试细节：

1. given-when-then，一个单元测试，遵守三个步骤，given构造数据，when什么条件、什么操作，then得到结果
2. 包名、类名、方法名。包在src/test/下，包名最好和生产代码包名一样，类名在生产类名前+test，方法名可以用test+方法名+场景，或者直接用when、then

思考怎么在项目中使用TDD，步骤：

1. 需求分析
2. 设计（类图、流程图）
3. 生成项目骨架，关键类、接口、方法(但不实现代码)
4. 编写测试，开始TDD，红-绿-重构

光看概念可能不理解，结合代码看，在最下方参考链接中都有代码示例。

参考（代码案例）：

ideaIDE文档，关于单元测试的功能、配合TDD： idea 功能：Tutorial: test driven development | IntelliJ IDEA

​​​​​Test Driven Development (TDD): Example Walkthrough | Technology ConversationsTest Driven Development (TDD): Best Practices Using Java Examples | Technology Conversations

Test-Driven Development: Really, It’s a Design Technique  

《构建高质量软件》试读，对单元测试和TDD讲解，推荐 http://images.china-pub.com/ebook8080001-8085000/8083973/ch01.pdf