您真的必须以测试优先的方式进行BDD / TDD吗？

即使我没有参加过TDD或BDD项目，或者我曾经在其中说他们正在进行TDD，但距离该项目还很遥远，但这些都是我在考虑的事情，实际上我会尽力阅读关于。

回到问题。在执行BDD时，您应该先编写“测试”并使其失败，对吗？然后实现该功能或您所说的功能。但是，如果您将其推向极致，那难道不是某种自上而下的开发吗？您正在查看自己的UI，并说：“我想在此使用此功能/行为”。然后，您可以修复UI以实现该功能以及支持该UI的代码。至此，您尚未实现任何业务逻辑或数据访问逻辑，而只是实现了行为。我要针对的目标不是先编写测试，而是先编写UI代码。在某些情况下，这将导致数据访问和业务层使用相同的代码，因为您使用UI代码来定义业务需要支持的内容。

当然，您应该为此进行补充测试，以确保该功能正常运行。

有什么想法吗？

您是从测试UI的高级角度谈论BDD。在此级别进行测试比在Javascript /服务器端代码中降低测试难度更大。

我在TDD上读过的几本书都说您应该像编写基础系统一样编写代码，并且编写足够的代码以使测试通过。您可以在服务器上编写存根，以使您的UI行为测试通过。然后，您从这个存根缝开始，为服务器端代码编写一些单元测试，然后逐步进行完整的实现。

我经常编写代码，就好像存在基础层以使高级测试通过一样，它的感觉就像是钻进一个兔子洞并提取许多其他类以满足高级测试，然后为这些较低级别编写测试。正如您已经认识到的那样，它可以帮助您从更高级的测试开始集中精力。

任何经验丰富的程序员都知道，软件开发有很多层次。我倾向于工作低于UI，然后考虑UI从服务器开始需要的数据或行为，然后从那里开始（也许是因为这些天我没有做太多UI工作）。

如果我真的很诚实，那么从底层提取类就意味着我不是先进行测试，而是……在几分钟甚至几小时内，我将对该代码进行测试。这对我仍然很有益，因为我可以帮助您了解在哪里需要为类提供依赖关系并遵守单一责任原则-如果难以测试，那么您在一个地方做得太多。

是! 否则，您将获得开发驱动的测试。

但是，实际上，存在使用“纯” TDD很难解决的问题。通过预先编写一些未发现的生产代码，并在以后的测试中进行覆盖（以及以后学习如何解决TDD中的类似问题），可以提高生产效率。请看一下这项技术，该技术的作者称其为漂洗重复TDD，因为它没有更好的用语。

如果您不先编写测试，就不会通过测试来推动开发。嗯，您不是在进行测试驱动的开发！

如果您想以这种方式工作，那就去吧。但这不是测试驱动的开发。

您所描述的内容听起来很像“ 前端设计”方法。不幸的是，前端设计是Alex Papadimoulis在敏捷方法上的讽刺。

我个人认为，在设计阶段考虑测试至关重要。拥有一个可行的实现确实很棒，但是唯一可以确保您拥有一个正常工作的产品的方法就是您已经对其进行了逐项测试。解决这个问题的方法是将单元测试与熟练的质量检查团队合作进行结合。

现在，如何将此准则安装到您的团队中就由您决定了。TDD是一种这样的策略-并且有其地位，还有许多其他变化。但是，TDD并不特别适合开发UI布局。