测试驱动开发（TDD）是类似极限编程（XP）这样的敏捷方法的核心实践，其对自动化测试的使用更多的是去编制软件行为的规格而不只是衰退测试。TDD的效能来自于让我们去单独的思考软件为两个阶段：它必须做什么，它必须如何去做。
敏捷软件开发在避开瀑布风格的开发吗？确实如此，敏捷人员喜欢按特性一个一个的设计和创建系统，每一步都可以获得工作软件来证实在开发下一个特性之前每个特性是可以工作的。这并不意味着我们不要去设计了，这简单的意味着我们去“连续的设计”。极端情况就是“紧急设计”，此时在最前面做很小的设计。基于一步一步的特性，我们可以在详细设计的最前面结合高阶设计（架构）。这样可以延迟对去实现某个特性的行为的思考，我们可以去捕获行为必须是怎么样的一种可执行的规格的方式。不管怎么说，我们多数人很难在某个时间只集中在一件事情上面。
一旦我们完成编写测试并证实它们像期待的一样失败了，这样我们可以转换看法让它们通过，现在测试是一种前进的度量。如果我们增量实现功能，随着我们编码的增加，我们可以看到一个一个的通过测试。随着我们工作的进行，我们继续运行先前编写的测试作为衰减测试，来确保我们的变更没有带来意外的侧面影响。这是自动化单元测试的真正价值：功能性不会意外的变更。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/14639675/viewspace-408752/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
敏捷软件过程的局限性
下一篇：
RUP是敏捷的吗？
请登录后发表评论
登录
全部评论
