鉴于短暂的(2周)冲刺,放弃TDD"完成任务"是否可以接受？

Question

鉴于短暂的冲刺,放弃TDD在冲刺中"完成任务"是否可以接受.

例如,一个给定的工作可能需要说冲刺的1/3来围绕现有实现设计对象模型.在这种情况下,你可能最终会得到实现的代码,比如sprint的一半,没有任何测试(在这个"设计"阶段实现单元测试会增加很多努力,测试很可能会丢失几次直到最终"设计"以此为基础).

然后,您可能会在第二周花一两天时间在事后添加单元/集成测试.

这可以接受吗？

Answer 1

我会说,如果它意味着你完成了一个你无法完成的项目,那么绕过任何过程几乎总是可以接受的.这些流程应该可以为您提供帮助,但是如果您的流程没有帮助,那么请不要使用它(当然,首先与团队的其他成员讨论).

然而,绕过TDD很容易产生完全相反的效果 - 您可以编写错误的代码,在您需要发货之前需要重写,因为最终测试会显示您应该更早发现的关键问题,因此请在此之前仔细考虑.

如果你跳过单元测试以获得一些东西,并且幸运的是它可以工作,你应该把它视为技术债务,应该尽快偿还.

Answer 2

对于很多人来说,2周的迭代并不短.我们中的许多人正在进行一周的迭代.Kent Beck甚至试图鼓励日常部署 - 并且清理开发过程有很多优势,因此可以做出响应.

永远不要降低TDD的质量来解决问题 - 以后清理起来要困难得多,你最后教给客户的是他们可以向你施加快速,肮脏,黑客攻击的压力.他们没有看到因此产生的垃圾代码 - 而且他们无法维护它.如果有人试图让我这样做,我就会放弃...而且我拒绝在"没有时间正确测试"的地方工作.这不是一个有效的借口.

注意:当我写关于TDD时,我包括功能测试.这些很重要,因为他们应该根据可识别的用户故事来运用对客户有意义的场景.我通常在功能测试的故事上开始工作,因为这是最重要的测试 - "测试客户获得他们描述的内容......" 所有其他测试可能需要进行协商,但是当我团队领先时,我至少期待每个故事的一次功能测试或者它(如scrum人们所说)"没有完成!" ;-)

不要以为你可以进去并在以后添加测试 - 这样做要困难得多.(我已经尝试了两种方式 - 相信我.)随着时间的推移,将测试放入进展真的更便宜 - 即使你必须重构和重写,或者随着系统的发展抛出一些.

如果没有合适的代码覆盖率,您无法获得高质量的代码.

代码测试覆盖率是这里的重要词汇.涵盖可能破坏的东西,而不仅仅是数以万计的毫无意义的测试 - 涵盖您需要担心的事情的关键测试.

如果你不能及时把它弄出来并且这是一个问题你需要思考为什么？

• 这是计划/发布计划问题吗？
• 是否有代码维护/重构问题可以解决问题？
• 是否有人对团队施加不合理的压力？(让CTO击败他们......)

Answer 3

如果你可以准确地编写没有测试的东西,为什么要使用单元测试？单元测试应该帮助您更快地编写代码或帮助编写更好的代码.如果不这样做,请不要使用单元测试.