谈谈对测试驱动开发思想的体会

最近学习了一本书《Python Web开发：测试驱动方法》，贯穿全书的便是测试驱动开发的编程思想。有点儿兵马未动，粮草先行的兵家思想。先简单总结一下这本书带给我的收获：1.学习了测试驱动开发的一种编程思想，与传统的瀑布开发流程又很大的出入。2.学习了如何写好功能测试，如何写好单元测试。3.先通过测试，再谈重构。

好，下面简单聊聊我对这种编程思想的体会。

何为测试驱动开发

维基百科中队测试驱动开发又一个比较正式的介绍：测试驱动开发（英语：Test-driven development，缩写为TDD）是一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。

按照我个人的理解：将业务需求转化为功能测试及单元测试，业务代码则为了通过测试而不断的迭代。

测试驱动开发利弊权衡（由于未实战过tdd，看法可能略显稚嫩）

通过测试驱动开发，能保证业务代码能满足需求，不断的重构，能保证系统功能的正常运行。但是对于代码质量的把控，貌似很难做到。
测试驱动开发思想其实并不难理解，流程无非也是在测试开发重构过程中不断流转，但是个人感觉在工程实践上其实难度挺大
就个人工作经验来看，目前多数企业对于项目代码质量把控很差，项目周期紧，领导总是抱着先上线，遇到bug再解决，故TDD的开发模式在很多公司，尤其是创业公司中很难推广开，由于前期测试覆盖度不够，开发急促，导致后期上线维护异常困难
TDD的开发模式也应该分业务场景而看，但具体是哪些场景合适目前没有资格谈

TDD这种方式，还是得实践。然而以目前公司的平台，基本属于不可能。不过，就算不能在公司实践TDD的开发模式，它其中最重要的核心部分–测试，会让我在今后的开发过程中更加重视这部分。