@msg7086
> 增加测试覆盖很好，但是我觉得 TDD 本末倒置了，很多时候为了测试而测试
-----------
同意，为了增加测试覆盖率而 TDD 就是本末倒置。

> 先写单元测试：…… 然后写代码 add_one(in)，会不会有人写成 return in == 4 ? 5 : 0 ？
-----------
如果程序员觉得先写成这一步有帮助，不妨写成这样再重构。当然不能停留在这里。原因是这种代码其实是重复，实现代码与测试代码之间“知识”的重复。具体就不多展开了。

> 先写测试再写方法，有很大的可能，会导致面向测试开发，而不是面向需求开发。
-----------
如果在没有实现代码的时候就不基于需求写测试用例，那确实会出现这种问题。

@ghostsf 没看懂，是说现实中不适合使用 XP 极限编程？

还是说 TDD 不适合 XP ？ TDD 不就是极限编程首先提出的么。

@q397064399
如果你的 testcase 在整个模块的生命周期就执行那么几次，然后又要被改动，那 testcase 的意义又何在呢？
---------
不能赞同更多。

所以我巴不得改代码的时候，每敲一下键盘就跑一次 testcase。

@q397064399

@lance0z TDD 不是敏捷开发的一项重要实践嘛。

我一直觉得，没自动化测试的敏捷都是假敏捷。

@Martin9 不好用啊，鼠标还是实际鼠标移动啊。

@we000 嗯，同意。如果是“被 TDD ”的话就是把人当猴子。

我自己做的主要动力是有了测试就能重构了，否则整天看糟心的代码又不敢改，有损健康啊。

@qile1 听起来很繁琐的样子，仿佛都能想象到各种调错的困难了。你是怎么搞定的啊？

@niubee1 既不能保证实现代码没有 bug，也不能保证 test 代码没有 bug。只是写代码的一种方式而已。

@chenxytw 我倒是觉得 TDD 特别适合整天改需求的情况。

如果需求特别稳定，写好了 30 年都不会变，那其实源代码没有了也没啥关系嘛是不是？

@sulang 我们也要求，但是没人理。说说你们怎么搞这么 nb 的。

我的感受是如果程序员自己想 TDD 很爽，如果被 TDD 就很不爽。

@Zeahoo TDD 基本概念很简单，好像是在解析极限编程里最先看到的。要想真正用起来摸索了很久。其间收获最大的书是 重构，修改代码的艺术，clean code。

@projectzoo 是的 vimium

图灵爷爷用的是打孔纸带

vim 用太多了，换一款纯鼠标操作的编辑器试试？

看医生，这是病，不是开导能解决的。

@Mrkon 试试 ctrl+o, j

:set rnu
显示相对于光标的行数，然后要下移 18 行的时候直接 18j。不用一行一行挪，或者自己算行数了

这跟 Spring Boot 有一毛钱关系么？