我对TDD很新,还没有开始使用它.但我知道我们必须首先编写测试然后再编写实际代码以通过测试并重构它直到良好的设计.
我对TDD的关注是它适合我们的SDLC.假设我需要制作订单处理系统.现在,如果没有这个系统的任何模型和设计,我该如何开始编写测试？我们不应该要求定义实体及其属性来继续吗？如果没有,是否有可能在没有任何设计的情况下开发大型系统？
有两个级别的TDD,ATDD或验收测试驱动开发,以及由单元测试驱动的正常TDD.
我猜TDD和设计之间的关系受到源代码是软件产品设计的"敏捷"概念的影响.许多人通过将TDD转换为测试驱动设计而非开发来强化这一点.这很有意义,因为TDD应该被视为与驱动设计有关,而不是测试.在最后接受验收和单元测试是一个很好的副作用.
在不了解更多信息的情况下,我无法真正说出它适合您的SDLC的位置,但一个不错的工作流程是:
对于每个用户故事:
使用FitNesse或Cucumber等工具编写验收测试,这将从用户理解的角度指定给定输入的所需输出.该级别可自动化规范,甚至可以在理想情况下替换规范文档.
现在,对于类/行为等可能需要的软件设计,您可能会有一个模糊的概念.
对于每个行为:
编写一个失败的测试,显示您希望如何使用该类的调用代码.
实现使测试通过的行为
重构测试代码和实际代码以反映良好的设计.
转到下一个行为.
转到下一个用户故事.
当然,你会想到系统不断发展的高级设计.理想情况下,TDD将在较低级别实现灵活的设计,允许适当的高设计随着您的发展而发展,而不是在开始时尝试猜测它.
它应该被称为测试驱动设计，因为它就是这样。
没有实际理由将设计分为项目的特定阶段。设计无时无刻不在发生。从与利益相关者的最初讨论，到用户故事的创建、评估，当然还有 TDD 会议期间。
如果您想使用 UML 或其他方式形式化设计，那很好，只需记住代码就是设计。其他一切都只是一个近似值。请记住，You Aren't Gonna Need It (YAGNI)适用于一切，包括设计文档。
| 归档时间： |
|
| 查看次数： |
1462 次 |
| 最近记录： |