过于真实
【 在 DoorWay 的大作中提到: 】
: 对了，我做的所有项目都不咋正规，单元测试基本没有、有业务自动化测试但用例设计也不咋讲究、以及纯靠开发自测就交出去，
:......

论坛助手,iPhone
--
FROM 180.173.63.*

还是看项目风格
需求明确，要求严格，资源到位，TDD当然很好。
需求每4小时大变一次，老板给的研发资源是正常水平的五分之一，你给我玩一个TDD看看

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

你说的问题是 TDD做到什么颗粒度吧？
是每增加一个功能就增加相关的测试用例，还是每增加一个函数就写对应测试用例。

我觉得应该因地适宜，灵活使用。
【 在 fafe 的大作中提到: 】
: 我们有测试用例啊，重要功能都有测试用例保护
: 但测试驱动这种模式还是太重了，得不偿失  
--
FROM 36.112.191.*

批评很容易，提出新的建设性意见很难，哈哈

要不试试弄点软件研发的新思路出来？
--
FROM 221.218.167.*

赞
【 在 DoorWay 的大作中提到: 】
我有时这么调侃自己和同事，哈哈

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

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

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

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