前两天，有读者留言分享了一次“惊险”的开发经历，临上线时，有个 bug 怎么找也找不到，连老板都加入了“找茬”行动，最后才发现，居然是赋值写错了，这一个小错误差点造成公司的巨额损失，心里一阵后怕。
他说，虽然平时知道单元测试很重要，但人嘛，大多数情况下还是对自己的代码很自信，所以觉得不写也出不了什么大事。直到这次差点翻车，才理解为什么那些技术大牛都多次强调：追求 100% 测试覆盖率才是保证代码质量的好方法。有测试保障，才能最大程度减少错误的出现。
很巧的是，Thoughtworks 中国区 CTO 徐昊迷上测试的理由也跟这个读者大同小异。虽然徐昊从小就热爱探索各种新技术，但他第一次接触 TDD（测试驱动开发）时仍有些抵触，因为 TDD 不仅每个步骤别扭，花费的时间还更长，仅仅一个范例就要写超久，所以他完全不认为 TDD 有被广大开发者长久使用的可能。
然而，真香永不缺席。
TDD 给徐昊的惊喜来源于他写完代码后，第一次启动应用程序。他发现竟然完全没 bug ，代码根本不用返工。而以前就算是自己再沉下心来写的代码，至少也要调试个五六回才能正常运转。
自此以后，徐昊开始强迫自己用 TDD 的方法来编写所有的程序，不管是应用类的项目，还是编译器全都不放过，逮住机会就用 TDD 。后来他不仅自己用，还在团队内部推行，带领大家一起用。
渐渐地，徐昊发现，团队成员的技术水平提高了一大截。原因一方面是，在使用 TDD 的过程中，需要大家把需求和架构拆分成容易转化成测试的任务，长此以往，任务分解能力、对业务的理解能力都练出来了。另一方面是，大家写测试的效率越来越高，在相同开发的时间内，现在既能收获一组可工作的代码，还能收获一组可用于定位问题的测试。
如今，徐昊把他自己和团队多年的关于 TDD 实践经验都融合在了这个《徐昊·TDD 项目实战开发 70 讲》的极客时间专栏里，包含超过70 讲内容、40 + 小时视频演示， 4 个完整的项目实践。通过它，你绝对可以搞定需求难理解、任务难拆分、TDD 难落地等难题。
结算时输入口令「xuhao6666」
立享 6 折优惠，到手189
徐昊已经跟 TDD 打了将近二十年交道，多次帮国内外的大小团队成功解决了 TDD 的落地，还发明了以 TDD 为核心的高效工作法，经验丰富。所以，想解决 TDD 使用过程中的问题，或对 TDD 感兴趣想多了解，他的专栏绝对是首选。
现在加入学习，除了一门硬核课程外，还附带高质量学习社群与徐昊亲自点评代码的福利，机不可失。
徐昊是怎么讲解 TDD 的？
正是因为 TDD 需要在不同的场景下练习才能掌握，这个专栏才以视频展示为主，图文讲解为辅。你能在具体的场景下，体会使用 TDD 和平时开发的差异。
首先徐昊将从一个编码练习（Code Kata）级别的小例子入手，展示使用 TDD 开发的全过程，让你有个直观的认识。
然后他会围绕这个例子，详细讲解 TDD 的核心理念与方法，带你深入讨论 TDD 中的测试到底是什么样的测试，TDD 是如何驱动我们的开发。他还会介绍 TDD 的经典学派（芝加哥学派）与伦敦学派不同的切入点。
在这部分的最后，他将会总结 TDD 作为工程方法的核心优势在什么地方。如果你需要说服周围的同事、朋友、领导开始采用 TDD 方法，这将给你提供足够的弹药。
接下来是实战项目环节。徐昊将以几个技术框架为例（IoC 容器、RESTful 框架、DB Mapper 框架等），展示如何使用 TDD 的方式从头来实现它们，TDD 实战的细节将一览无遗。
不仅可以教你如何用，也可以教你如何说服别人一起用。具体章节，可以看看目录
曾听说过一句很经典的话：如果关注质量，那长期来看质量会提升，成本会降低；如果关注成本，那长期来看成本会提升，质量会降低。
这句话也同样适用于测试驱动开发，对高质量代码和高质量软件系统的追求，会推动着我们成为越来越可靠、越来越有竞争力的开发者。
结算时输入口令「xuhao6666」
立享 6 折优惠，到手189
是时候见识一下真正的敏捷开发了，现在加入学习，除了一门硬核课程外，还附带高质量学习社群与徐昊亲自点评代码的福利，机不可失。
测试驱动开发
牛人想带你见识见识
营业执照公示信息