假设我有一堆用户故事（由于我与我的团队一起进行的计划会议）。我还没有申请中的任何代码，而是从我的'A'开始 或最高优先级故事/史诗
比如说
“作为用户我应该能够搜索更多用户，以便我可以在网站上添加更多朋友”
那么团队应该如何在进行TDD时编写应用程序代码。
团队开始创建单元测试，即负责创建模型
然后每个人都会讲故事并开始编写功能测试来创建我的控制器/视图（所以他们应该在编写功能测试时进行集成测试）
然后进行集成测试
我实际上很困惑集成测试如何适用。如果所有集成测试都有效（即所有功能，单元测试都应该通过）
因此，如果应用程序刚刚启动（即尚未编写代码）。当TDD / BDD拿起故事并开始从头开始实施应用程序时，人们通常采用什么流程
答案 0 :(得分：6)
非常好的问题！ TDD / BDD方式建议您使用用户故事并编写验证点（阅读高级测试）。他们使用GWT（Given / When / Then）说如下。
“作为用户，我应该能够搜索更多用户，以便我可以在网站上添加更多朋友”
given the website URL
when the site loads
then a search field should be visible/accessible.
这是您与产品所有者进行迭代的第一条反馈和第一次机会。询问搜索栏应该去哪里？它应该自动完成吗？等等。接下来，您将“行为分配给UI对象。这些行为也有验证点。
这将定义搜索按钮的行为：
given a go button next to the search field
when then button is clicked
then a search should be performed
这将描述您的搜索逻辑：
given a search term "John" and a user set including "John, Joan, Jim, Steve"
when a search is performed
then the results should contain "John" an "Joan"
第一个验证点将描述将控制器搜索按钮链接到实现搜索算法的任意模型的行为。第二个验证点描述了搜索算法本身。优点是这些部件是独立定义的并且可以并行设计。它还为您提供了一个很好的API，并且很容易规划要迭代的功能。它还使您能够在不影响其余部分的情况下迭代/优化任何拼图。
更新我还想提一下，我所称的验证点可以与UAT或用户验收测试松散相关。不要被这些条款挂断，因为它们无关紧要。专注于他们背后的想法。您需要了解用户故事并将其细分为规范。 （可以使用UAT或验证点或两者进行一次或多次传递，或者魔术只是确保你将它们分解。）如果你的用户故事被打破了，可以用FitNesse，JUnit等工具编写，或者RSpec然后使用这些工具中的一个，否则你需要进一步的对话（你的用户故事是否过于模糊？）或另一个你需要进一步分解的内容（UAT到验证点）。不要痴迷于工具，感觉你需要从一开始就自动化所有东西。离开Selenium，直到您完成手动过程。最终，您需要可以使用程序化测试形式编写的规范，此时您应该能够使用像JUnit这样简单的东西来开始编码。当你变得更好/更好，你可以选择EasyB或RSpec故事跑者和其他东西。
答案 1 :(得分：4)
这是我们通常从Sprint 0开始的地方，在今年春天，我们将拥有XP调用的Spike Session（或抛弃代码会话）。在此会话中，您可以开始进行原型设计。
在你的会话中写一些用户验收测试（最好是BDD格式）然后开始编写测试以匹配你的一个UAT。
例如：
请求搜索 用户名是“testUser”的位置 应该返回1个结果。
有了这个，你现在有了第一个测试的目标，你编写，然后开始编写代码以使测试通过。随着你的前进，你应该开始看看应该如何组合应用程序来完成故事。
然后我将在下一个sprint构建故事/任务中开始，根据您在sprint 0中发现的内容，根据需要完成该功能。
答案 2 :(得分：2)
首先，将故事分开。你需要：
现在，您拥有该模型。接下来，您对控制器执行相同操作。当它们工作时，您可以从视图开始。
或者，当你是专业人士并且已经完成了这一千次之后，你可以一次完成几个步骤。
但你必须先把问题切成易碎的部分。
接下来进行集成测试。他们将模拟用户的行为。在一般情况下，您需要编写一组单元测试（它们只是称为集成测试，但您也应该能够自动运行它们）。这些测试需要像用户一样与Web应用程序进行通信，因此您需要模拟Web浏览器等。
答案 3 :(得分：2)
如果您正在进行TDD，则首先要进行一项测试，该测试表明系统不会执行用户故事所描述的所需行为。如果以您期望的方式失败，通过有用的诊断，您可以通过添加或修改类来开始实现行为，首先进行单元测试。
因此，在TDD中，您在编写单元测试之前编写集成测试。
为了引导整个过程，人们通常会编写一个“行走的骨架”：一个可以执行最薄切实际功能的系统。步行骨架让我们构建了针对简单功能的集成测试基础架构。
然后项目的其余部分充实了骨架。
答案 4 :(得分：2)
“我真的很困惑集成测试如何适应。如果所有的话 集成测试工作（即所有功能，单元测试都应该通过）“
这取决于。当然，可以通过所有单元和功能测试通过的方式编写集成测试。这要困难得多。
想象一下，你有3个模型，3个控制器和3个视图。想象一下，所有都非常简单，没有条件或循环，每个都有一个方法。
您现在可以（单位）测试这些中的每一个，总共9个断言并具有完整的覆盖范围。您可以进行集成测试，以确保所有这些功能能够很好地协同工作。
如果您跳过单位/功能并且需要完全覆盖，那么您将需要27个断言（3 x 3 x 3）。
在实践中，事情当然更复杂。您需要更多的集成测试才能达到相同的覆盖水平。
另外，如果你练习TDD / BDD，那么无论如何都会经常进行大量的单元测试。集成测试是为了确保所有这些部件完美地结合在一起并完成客户的需求。这些部件本身已通过单元测试单独测试。