17 | TDD 就是先写测试后写代码吗？

TDD是两头驱动：向前驱动出任务分解，软件设计，整洁架构；向后驱动出代码重构，整洁代码。

早上下单购买了《修改代码的艺术》。看到了遗留代码的定义。才知道原来这些年自己写的代码，或者是项目中其他“大神”写的代码都是遗留代码。下定决心，为自己以后能高效工作。单元测试代码不能少。沉下心来，学好程序员必备的测试技能。

希望老师可以用一个简单的demo，来展示tdd的落地是如何进行的。理论非常动人，但是我个人觉得落地比较困难

不知道开发同学能不能理解，我说一个测试角度的例子。 我面试时，会问一个简单的编码题，就是写一个函数，接收三个参数，分别是 2 个运算数和 1 个运算符，这个函数就把他们做个简单的运算，输出运算结果，其中，运算符只支持加减乘除四则运算。 大部分人写完后，我会继续让他写一下针对这个函数的测试点（测试用例的一句话版本）。 很简单吧？ 但是会发现一个现象，比如大部分人设计用例时，都会有一条是「验证输入非法运算符时，输出提示错误」，但是他们的代码里面明明没有对这个逻辑的处理。 这我理解就是没有 TDD 的思想，TDD 除了想着功能要如何实现，还需要考虑会从哪方面「测试」，从而在编码时就可以考虑/设计的很完善。

今天入门了TDD，第一次接触极限编程，感觉离大佬近了点

所以测试驱动开发，首先要有设计，然后再有任务分解，然后才有测试代码，然后再驱动前面的设计，向后驱动具体的实现，保证红绿闭环

从测试的视角出发看待代码。--记下来

以前不会也从来没写过测试，看了老师的专栏后，我已经在平时会刻意写一些单元测试了。

虽然没有系统的学习过tdd，但是目前写单元测试的流程就是按老师所说。对于其中的任务分解其实还是认知不够明确，目前只能按照自己对于业务的理解主观的拆分，但是对于粒度的把握没有明确的概念，这块希望老师能解答下？

为了写好单元测试，我们需要解决的是代码设计中的依赖耦合问题。而TDD的重构环节，我们要解决的是代码的坏味道。坏味道就多种多样了，用代码扫描工具可以扫出很多来。那么是否有哪些类型的坏味道是需要重点关注的，会造成较大影响的，从而需要优先重构的呢？