- 主题:回想一下，很多码农所谓的开发模式，都是垃圾
你有这种看法，估计是因为
1. 你其实没学会tdd
2. 你的项目太多变，不适合tdd
【 在 fafe 的大作中提到: 】
: 比如曾经还参加过一个培训，测试驱动开发
: 就是大家写主体代码之前，先写好测试用例。
: 然后完善测试用例，让测试用例通过的过程，就是主体代码开发的过程。
: ...................
--
FROM 123.120.187.*
如果你的项目对测试覆盖率有要求，那你不出一年就会发现，tdd太爽了，会促使你从一开头就做好解耦，做好依赖倒置，基本就不需要操心mock之类的事情了
如果项目不要求测试，自己也不给自己要求测试，那。。。。咳咳。。。就是bug驱动开发呗
【 在 fafe 的大作中提到: 】
: 何出此言啊？
--
FROM 123.120.187.*
自动测试是硬要求，具体每个人是tdd还是先写逻辑后补测试随意
我个人遇到需求描述明确和稳定的场景会倾向用tdd
【 在 fafe 的大作中提到: 】
: 你们现在是tdd吗？
--
FROM 123.120.187.*
赞
【 在 DoorWay 的大作中提到: 】
我有时这么调侃自己和同事，哈哈
新项目我主导时，是杂糅的方法论，DDD做架构，
概念模型、对象模型、系统模型，画实体图、用例图、类图、交互图、模块图、重难点分析、任务拆解、并行依赖分析等。
其中用例图基本就是TDD的思路，用例就当成测试用例，写一通类和接口，假数据
调通，给需求演示下（反交底），证明没理解歪。同时其他同事也参加，看一下，算是对架构传达。
这一步也是架构落地，即搭好框架，让更多开发进来。为了保证每个人都没理解歪，也会给不同模块都写几个“测试”，其实就是功能，或者让大家自己写，一起演示下。点不同得菜单，弹出个MessageBox，假装写好了，分清楚大家连接的“边界”。
这种方法起手的话，后面大家交流时，A往往对B说，我给你写个“接口”吧，到时你实现下。其实这时候写的，有时不是“接口”，而是对B的测试用例。保证B的输出能被A使用。
以上是理想情况。有时去别的项目救急，没有这一套，学究点说代码表达业务非常差。就安慰自己，BDD，先改了/加上再说。也用于鼓励开发同事。
【 在 fafe 的大作中提到: 】
: 何出此言啊？
--
FROM 123.120.187.*