Test Driven Development。测试驱动开发，提倡在开发足够多的代码之前优先写单元测试，然后重构开发者编写的源代码。初学者会问，源代码都没有怎么写单元测试？请注意是开发足够多的代码之前，也就是会有少量源代码工作在单元测试之前，如功能模块骨架，方法定义、类依赖。
三个准则：
- 定律一、在编写不能通过的单元测试前，不可编写生产代码。(写生产代码前，先写针对其需求的单元测试，当然因为生产代码还没写，这个单元测试肯定是失败、无法通过)
- 定律二、只可编写刚好无法通过的单元测试，不能编译也算不过。(测试小步走，写一个单元测试不要一下子写太多测试功能，如编译不通过，如果生产代码还没写，那单元测试代码肯定编译不通过，这就够了)
- 定律三、只可编写刚好足以通过当前失败测试的生产代码。（生产代码小步走，生产代码要基于测试代码，先写测试代码再写生产代码，测试失败什么、生产代码才能写什么，）
测试代码要求：和生产代码一样重要，必须规范、必须有可读性。
TDD 生命周期。(遵守这六个步骤)
- 编写测试。（首次写一个测试类，此时没有写生产类，导致编译失败，再去创建生产类，就能编译通过）（或写其他逻辑条件的测试用例）
- 运行测试（生产类没有实现代码，测试不通过）
- 编写足够的实现代码以使测试通过(实现生产类，关注于实现功能)
- 运行所有测试（每次对类修改，?都要进行测试，测试不通过就回到步骤3）
- 重构(不断疯狂重构，每次重构运行单元测试，测试不通过就回到步骤3，重构可能会产生新类、新方法，如果有必要也应该增加单元测试)
- 重复（重复整个流程，直到所有测试条件都能通过，并且覆盖所有代码的逻辑分支、如ifelse分支）
以上6步是详细步骤，此外有名的 “TDD 红-绿-重构”是对步骤的总结。
单元测试细节：
- given-when-then，一个单元测试，遵守三个步骤，given构造数据，when什么条件、什么操作，then得到结果
- 包名、类名、方法名。包在src/test/下，包名最好和生产代码包名一样，类名在生产类名前+test，方法名可以用test+方法名+场景，或者直接用when、then
思考怎么在项目中使用TDD，步骤：
- 需求分析
- 设计（类图、流程图）
- 生成项目骨架，关键类、接口、方法(但不实现代码)
- 编写测试，开始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