比如曾经还参加过一个培训，测试驱动开发
就是大家写主体代码之前，先写好测试用例。
然后完善测试用例，让测试用例通过的过程，就是主体代码开发的过程。
刚接受这培训的时候，觉得这牛逼哄哄的。思想好牛啊。
可做了一下，立马感觉到，本末倒置了。
现在也看不到这种开发模式了。
  
--
FROM 123.123.42.*

你有这种看法，估计是因为

1. 你其实没学会tdd
2. 你的项目太多变，不适合tdd

【 在 fafe 的大作中提到: 】
: 比如曾经还参加过一个培训，测试驱动开发
: 就是大家写主体代码之前，先写好测试用例。
: 然后完善测试用例，让测试用例通过的过程，就是主体代码开发的过程。
: ...................
--
FROM 123.120.187.*

如果你的项目对测试覆盖率有要求，那你不出一年就会发现，tdd太爽了，会促使你从一开头就做好解耦，做好依赖倒置，基本就不需要操心mock之类的事情了

如果项目不要求测试，自己也不给自己要求测试，那。。。。咳咳。。。就是bug驱动开发呗
【 在 fafe 的大作中提到: 】
: 何出此言啊？
--
FROM 123.120.187.*

哈哈，有趣有趣
【 在 DoorWay 的大作中提到: 】
: 猜测你是BDD，bug 驱动开发。  
: --

发自「今日水木 on iPhone SE 2」
--
FROM 183.194.161.*

我有时这么调侃自己和同事，哈哈

新项目我主导时，是杂糅的方法论，DDD做架构，
概念模型、对象模型、系统模型，画实体图、用例图、类图、交互图、模块图、重难点分析、任务拆解、并行依赖分析等。

其中用例图基本就是TDD的思路，用例就当成测试用例，写一通类和接口，假数据
调通，给需求演示下（反交底），证明没理解歪。同时其他同事也参加，看一下，算是对架构传达。
这一步也是架构落地，即搭好框架，让更多开发进来。为了保证每个人都没理解歪，也会给不同模块都写几个“测试”，其实就是功能，或者让大家自己写，一起演示下。点不同得菜单，弹出个MessageBox，假装写好了，分清楚大家连接的“边界”。

这种方法起手的话，后面大家交流时，A往往对B说，我给你写个“接口”吧，到时你实现下。其实这时候写的，有时不是“接口”，而是对B的测试用例。保证B的输出能被A使用。

以上是理想情况。有时去别的项目救急，没有这一套，学究点说代码表达业务非常差。就安慰自己，BDD，先改了/加上再说。也用于鼓励开发同事。
【 在 fafe 的大作中提到: 】
: 何出此言啊？
--
FROM 61.185.161.*