TDD应该在初始原型阶段应用吗？

Question

我有一个关于在早期开发阶段应用tdd的问题。通常，在开始开发项目时，客户端并不确切地知道具体要求是什么，因此在看到第一个原型后会对其进行更改。如果我们从项目的最初阶段开始应用tdd，那么很快我们的测试（接受，集成，单元​​）的很大一部分将被删除或更新。这是正常的吗？如果没有，如何在产品开发的初始阶段进行？

Answer 1

我会安慰你，马库斯：客户在一开始就改变主意是正常的。有趣的是，即使有时间，他们唯一不改变主意的是改变他们对事物的看法。

所以不要担心你的测试的某些部分会随着实现一起进入bin，因为它在后期会是相同的。你可以做什么作为开发人员/ BA /无论如何尽快指出他们正确的方向，与他们讨论事情，这样你就不会开发太多“无用的”东西。

特别是如果您以非常敏捷的方式工作，需求可能会从迭代变为迭代，这绝不应该让您认为测试在项目的任何阶段都是无用的。

当需求发生变化时，测试更新是非常正常的。人们需要开始更严肃地对待测试（这是srs business，k ?!）并且意识到它是：a）不仅仅是为了惹恼你，b）应该随着项目而发展，因为它最有可能拯救你很麻烦。

Yishai建议的原型是一个很好的解决方案。有时。但你真的需要提防。在很多情况下，当客户看到原型时，他喜欢/非常类似于他想要的东西，他会想“哇，你几乎已经完成了！我们什么时候可以推出它？”？然后很难解释它只是一个原型，你需要从头开始。在许多情况下，人们只是开始使用原型作为主项目，他们不想添加缺少的测试或改进现有的代码库。这几乎就是我目前正在使用的应用程序的创建方式（现在已超过10年了！）。

Answer 2

是的，这是正常的。

另一个选择是，你可以构建真正的原型来获得一些反馈来确定一些以后无法改变的技术架构问题，并在没有测试的情况下构建它们。但是，要求的是，当真正的项目工作正在进行时，这些原型会被删除（他们最初可能会留下来看看有些事情是如何完成的等等，但最终产品中没有留下一滴代码）。

您还应确保编写的验收测试代表用户实际需要的功能，而不仅仅是您构建的工件。很多验收测试都会被抛弃，这似乎很奇怪。他们可能需要更新，以表示新的要求，但一般来说，如果你先做最重要的事情，它们应该是非常准确的，因为不应该改变。

但有时候他们真的不知道自己想要什么，或者技术能做什么，所以事情会发生根本变化。无论如何，这些都是高风险/高成本的项目。

Answer 3

如果有任何单元测试可以帮助您提前澄清要求，那么事情总会发生变化。集成测试可能会稍晚一些，但除非您的原型丢失，否则我会尝试从一开始就编写单元测试。像任何事情都有妥协，但是尽早编写测试有助于。在需求变更时更改测试将有助于验证这些变更。

Answer 4

我同意Zenzen的观点 - 向客户展示一个工作原型，当你声明它需要重写时会产生一种疑惑，可疑的外观。

和Yishai一样，我相信首先制作一次性原型，因为在客户面前放置一个视觉模型可以了解他们真正想要的东西（大多数人都没有得到任何线索，直到你告诉他们）..

然而，这个视觉原型激发了客户全新的想法，因此不可避免地要求改变......

所以，我的方法：

• 保持原型尽可能简单和静态模拟（无TDD）。
• 当我被要求展示真实世界的功能时，我认为这是开始（Full TDD）。