先设计测试用例代码，开发一个功能能够让提前设计的测试用例都可以通过？
测试驱动开发，即先根据用户的实际需求编写测试用例，再根据测试用例来完成功能代码
1、保证开发的功能一定是符合实际需求的。
质疑这一条，开发人员也不能随便开发，要按照产品经理提供的需求啊。
2、更加灵活的迭代方式。
3、保证系统的可扩展性。
4、更好的质量保证。
5、测试用例即文档。
TDD 的整个过程遵循以下流程：
为需要实现的新功能添加一批测试；
运行所有测试，看看新添加的测试是否失败；
编写实现软件新功能的实现代码；
再次运行所有的测试，看是否有测试失败；
重构代码；重复以上步骤直到所有测试通过。
每添加一个新的功能点，都会添加一个测试方法；完成新功能点的软件代码后，
接着运行当前所有的测试用例，以保证新加
的功能代码能够满足现有的测试需求。这就是一个典型的 TDD 过程了。
（这里举例子写了测试代码）
虽然大家都能看到 TDD 的优势，但是在实际项目中的运用还是比较有限。
tdd一定要求测试有很好的代码能力。
TDD 的核心思想便是在开发人员实现功能代码前，先设计好测试用例，编写测试代码，
然后再针对新增的测试代码来编写产品的功能代码，最终目的是让新增的测试代码能够通过。
相对于传统软件开发流程，TDD 的优势主要包括对需求精准的把控、更灵活的迭代、
促使更好的系统设计、更好的交付质量以及轻量级的文档等。
评论：
【虽然 TDD 并不适合所有项目，但是将 TDD 思想放大到整个开发流程上，我总结了一套开发流程，请大家参考。
所有人员参与需求评审 -> 测试人员编写测试用例 -> 所有人员参与用例评审 ->
开发人员按照测试用例进行编码 -> 开发人员执行用例，进行自测，所有用例通过后 ->
开发人员提测 -> 测试人员进行测试。
其中的好处个人觉得主要有两点：
1. 在编码前完成测试用例，可减少开发中需求变更带来的风险。因为在写测试用例的时候，
会对需求进行深度分析，思考需求是否合理，在我的经验中，测试组一定会发现不合理的需求，
如果这些不合理的需求在编码前就被发现，后面返工的几率就小很多；
2. 在自测环节，开发人员保证所有用例都通过，可以减少测试环节的轮次。
因为如果提测质量太差，会增加测试人员和开发人员沟通成本，
如果一些基本问题能在自测环节解决，那测试人员会有更多精力放在探索性测试、
压力测试、整体功能回归等测试中。
(新浪是这样测试的？)
不是所有的项目都适合tdd，而且采用tdd对测试人员的要求会很高。我的建议是一些小型的poc项目，
或者是功能相对单一的微服务开发是比较适合tdd的。另外，要推动tdd，
一定需要改革整个研发的流程，这个往往是十分困难的，也正是这个原因，实际开展tdd的项目也不是很多。
】
推荐书 《测试驱动开发》
（感觉TDD是在需求和开发的代码之间介入，用测试用例代码来引导开发代码的实现，
另外，TDD必须是测试用例代码，而不能是测试用例吗？）