前言
最近有幸跟随资深ThoughtWorks咨询师熊节老师一块儿学习测试驱动设计，通过短暂的十几天培训，对测试驱动设计的基本原则、实践模式、技巧有了一点点初步的认识。 编程
在此以前，常常自嘲我经历的公司实践也彷佛是TDD， 这种实践每每都是由测试工程师来驱动开发者完成bug的修改，虽然也是测试来驱动开发，可是却与真正的TDD截然不同。工具
什么是TDD
post
测试驱动开发（英语：Test-driven development，缩写为TDD）是一种软件开发过程当中的应用方法，由极限编程中倡导，以其倡导先写测试程序，而后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。
测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，经过去除冗余的代码，提升代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。
测试驱动开发也是国外许多优秀开发者向开发者们推荐的一种广泛适用的开发模式，而在熊节老师的培训课程中，他时刻在向开发者灌输来自TDD的三条原则，要求咱们的编写生产代码前，必定应该先编写单元测试。单元测试
定律一：在编写不能经过的单元测试前，不可编写生产代码。
定律二：只可编写恰好没法经过的单元测试，不能编译也算不经过。
定律三：只可编写恰好足以经过当前失败测试的生产代码。
简单实践
在我以前的编码实践过程当中，老是习惯梳理一遍逻辑后，在根据项目的实际状况对代码进行重构，而随着我自觉得掌握了单元测试的技巧以后，就开始把逻辑代码往单元测试上套，致使这样的单元测试实际上并不是为了实现测试，而仅仅只是程序的入口而已。学习
若是使用TDD的方法，则须要首先规划须要实现的目标，而后再定义测试方法和测试须要实现的逻辑。测试
例如，代码大概是这样的：ui
个人目标是实现对Schema对象的解析，测试类采用SchemaUnitTest，并采用“should_xxx_when_xxx”的命名方式，定义了测试方法“should_return_true_when_bool”，而后定义一个Schemas的类，再定义其须要实现的需求（断言），以及需求的实现。编码
对单元测试方法的命名，不一样的书籍有不一样的命名方法，在这个项目实践中，采用的是should命名方法，而在以前看过的《单元测试的艺术》一书中，使用的is_when_return_xxx的方式，这二者只是命名方法的不一样，本质上没有任何区别；使用xunit和mstest实际上也没有太多区别。spa
此时，这个定义的方法GetParameter是未实现的，因此会进入一个“红-绿-重构”的工做流程。设计
1）编写一个会失败的测试，以证实产品中代码或功能的缺失。编写代码时，要假设产品代码已经能工做了，这样测试的失败就说明产品代码中有缺陷。例如我定义的GetParameter方法使用xunit进行测试会提示失败， 只有在添加须要的代码后，编译才能经过。
2）编写符合测试预期的产品代码，使测试经过，产品代码应该尽可能简单。
3）重构代码。若是测试经过了，你就能够编写下一个单元测试，或者重构，消除异味或提升代码可读性。
最终，我完成了一个这样的方法。（即使是这样的代码，依然有许多能够进一步提高的空间。）
显然这是一个逻辑很是简单的代码，可是若是采用全键盘操做，不使用鼠标来完成，仍然耗费了我很多时间，这个过程当中，也让我对Visual Studio的快捷键操做更加熟练。
测试的不一样阶段
在咱们的产品研发过程当中，常常遇到如下三种不一样形式的测试
- 端到端测试：端到端测试侧重于软件功能应用层面的测试，主要使用人工或自动化的形式对用户界面进行测试。每每须要覆盖系统的各个功能，须要耗费的人力物力较大。
- 服务测试：主要集中在服务接口层的测试，能够经过PostMan等测试工具对接口的稳定性和可用性进行测试。侧重于接口行为实现。
- 单元测试：针对代码层面，例如单个方法或单个类实现的测试。属于白盒测试的一种。
三种测试从上到下实施的容易程度递增，可是测试效果递减。端到端测试最费时费力，可是经过测试后咱们对系统最有信心。单元测试最容易实施，效率也最高，可是测试后不能保证整个系统没有问题。
在咱们的项目实践中，更多的采用的依然是端到端测试的模式，彷佛只有经过测试者的人肉测试，才能让咱们的代码更加使人满意。
单元测试事实上极少在咱们的项目中获得实践，其主要缘由大概是由于要掌握单元测试方法，自己须要对开发者的主观能动性提出了更高的要求，可是996开发者...太容易内卷化了。
总结
写好单元测试历来就是技术活，有一段时间过度在乎理论概念和工具的用法，忽略了实践，因此实际上看了好几本书，依然不知道如何写单元测试，此次参与了培训，终于摸到了一点点影子。
现阶段我大概能够这样作来逐步提升本身的技能水平：
- 一、小步快跑，注意节奏：不要过分在乎某个需求的快速实现，而是编写可以在五分钟内快速完成的代码，并确保其经过。代码行控制在五行之内，代码的缩进层次，控制在两到三层。
- 二、练习，练习，再练习：写代码历来不是一件容易的事情，按照一万小时定律的说法，若是期望几天就熟练掌握显然不太现实，将来须要更加积极的练习，才能真正掌握。
- 多思考、努力写好代码：写几行代码其实并不难，难的是写高质量的代码。不要急于代码实现，要多思考上下文逻辑，让代码更加优美。
参考资料：
