我真的很困惑。假设我的用户故事是这样的。
"用户必须能够查看联盟中每个球员的统计数据，以便进行侦察正确地"
也许用户的故事很糟糕，但我该如何TDD呢？我应该测试一下我期待的房产吗？我在这里真的很失落，很感激你的观点。
编辑：我对TDD还很陌生，但我掌握了基本知识，并做了一些卡塔
您所描述的代码对TDD来说还不够精细，但您可以将其分解。
首先，如何向他们提供搜索所需的信息？他们会看到所有的统计数据吗？搜索玩家？搜索特定的统计？这为您提供了更细粒度的行为，现在您可以开始考虑用户将使用的接口。想想用户所做的事情的一个例子——也许是搜索玩家，也许是访问第一个页面，等等。让它变得有趣但简单。
一旦你知道UI的这一部分会是什么样子，你就可以对它进行编码。
UI将希望从某个地方获得一些信息，并将一些信息传递回。你会发现自己在考虑一个协作类——可能是一个控制器或演示者——这将有助于UI。反过来，该控制器将希望控制其他一些类之间的交互——UI本身、玩家统计信息、安全性、验证等的存储库。这是您编写测试的第一个类。
您现在可以开始为控制器编写测试了。你已经知道UI将如何使用它了。只需写一个例子，说明另一个类如何能够以同样的方式使用控制器，控制器需要什么样的信息，以及当你使用它时会得到什么结果。
当然，您还没有任何其他类，控制器可能需要它们。为这些类将扮演的角色使用接口，依赖注入它们，并在测试中模拟或截断它们。
在某个时刻，控制器将准备好做一些事情，但您仍然无法运行应用程序，因为您还没有完成协作类的编码——它们仍然只是接口。对它们再做一次同样的事情——假设你是控制器，使用它们，如果它们需要任何其他类，则模拟或截断它们。
最终，您将没有任何要模拟或存根的类，用户界面中的第一个场景将运行。如果你想获得更快的反馈，在任何时候你都可以硬编码一些数据，这样UI就可以运行，你可以看到它的样子。
这样做在中被称为外部，与BDD有关，BDD是一种稍微不同的TDD思考方式。我希望这一页能对你有所帮助。
您基本上是正确的。你没有说明你之前是否有单元测试或TDD的经验，所以我不知道接下来的内容对你来说会有多少翻新。
你从写一个你知道会失败的测试开始。在您提供的示例中，假设您的Player类没有Stats字段。因此，您编写了一个测试，以确保您可以访问Stats字段。它将失败；它甚至可能不会构建，因为您引用的字段还不存在。然后添加字段。测试通过。然后循环再次开始。
假设你有一个特定的统计数据，它是根据其他统计数据计算出来的。在编写逻辑来计算统计数据之前，您编写了一个失败的测试来检查统计数据的存在。它将失败。您实现了生成stat的逻辑。测试通过。重复
试试Roy Osherove的这些TDD卡塔，他写了一本精彩的书《单元测试的艺术》。
我希望这能有所帮助！
从这里开始，您需要创建更好地描述实际步骤的任务。每项任务通常不应花费超过12小时才能完成。例如，一个任务可以是"将RPI添加到列表玩家页面的列中"。从这里，您可以开始编写测试。
假设您使用某种MVC框架，您可以编写一个测试来检查您的模型是否可以报告RPI。然后，您可以编写一个测试，以确保您的控制器正在为视图提供RPI。最后，您可以编写一个测试，以确保您的视图在提供RPI时会显示RPI。
在Rails中，我会在实际测试运行之前，将一个已知的RPI添加到已知播放器的测试数据库中。然后，我可以写一个单元测试，看起来像这样：
known_player.rpi.should == 0.6902
所有这些测试都将失败。然后，当你开始实现每个实际的功能时，你应该再次运行测试，并观察它们是否开始通过