我对学习如何使用 TDD 正确开发软件感到非常沮丧。似乎每个人都以不同的顺序和不同的顺序做这件事。在这一点上，我只想知道所有考虑因素是什么？这就是我想出的：我应该使用 rspec 和 capybara。话虽如此，我需要编写哪些不同类型的测试，才能拥有一个构建良好且经过测试的应用程序。我正在寻找一个列表，其中包含我正在测试的应用程序区域、测试它所需的框架以及任何依赖项。
例如，似乎人们建议先对模型进行单元测试，但当我观看 TDD 教程时，他们似乎只编写集成测试。我错过了什么吗？
【问题讨论】：
标签： ruby-on-rails rspec tdd capybara
嗯，主题“你如何进行 TDD”与主题“你如何正确测试？”一样公开。在 Ruby 中，更具体地说，在 Rails 中，rspec 应该是开始使用的工具，但不是结束。 RSpec 允许您为组件编写单元测试，以单独测试它们。在 Rails 上下文中，这意味着：
它是一个非常好的工具，不完全是rails-bound，它也用于测试其他框架。
在你完成 RSpec 之后，你应该跳到黄瓜。 Cucumber (http://cukes.info/) 是编写集成测试最常用的工具（同样，用于 Rails 环境）。然后你可以在黄瓜上整合水豚。
在您完成 cucumber 之后，您将完成对应用程序后端及其（部分）HTML 输出的测试。那时您还应该测试您的 javascript 代码。怎么做？首先，您必须对其进行单元测试。 Jasmine (http://pivotal.github.com/jasmine/) 是您可能用于这项工作的工具之一。
然后你必须测试它在你的结构中的集成。怎么做？您将回到 cucumber 并将 selenium (http://seleniumhq.org/) 与您的 cucumber 框架集成，您将能够在浏览器中“实时”测试您的集成，访问您的 javascript 魔法和测试它当场。
因此，在您完成这些步骤之后，您就已经了解了拥有良好集成测试环境所需的大部分步骤。我们完了吗？并不真地。您还应该设置一个覆盖工具（一个可用的：https://github.com/colszowka/simplecov）来检查您的代码是否经过了很好的测试并且没有留下任何松散的结局。
在您完成这些无聊的步骤后，您还应该做最后一件事，以防您不是一个人开发它并且团队足够大以使其仍然无法自行管理：您将设置一个测试服务器，除了定期运行所有前面的步骤并发送有关其结果的通知外，什么都不做。
因此，所有这些都为感兴趣的开发人员设置了一个良好的 TDD 环境。我只为不同类型的测试命名了 ruby/rails 社区中最常用的框架，但这并不意味着没有其他框架可以或更适合您的工作。它仍然没有教你如何正确测试。为此，涉及更多的理论，以及很多子辩论。
如果我忘记了什么，请在下面的评论中写下来。
除此之外，您还应该了解如何正确测试。也就是说，您要采用声明式还是命令式方法？
【讨论】：
从简单开始，并根据需要添加更多工具和技术。有很多方法可以 TDD 一个应用程序，因为每个应用程序都是不同的。一种方法是从使用 Rspec 和 Capybara（或 Cucumber 和 Capybara）的端到端测试开始，然后根据需要添加更细粒度的测试。
当 Capybara 测试需要几分钟才能通过时，您知道您需要更细粒度的测试。
此外，如果您的应用程序的域不重要，那么首先开始测试域可能会更有成效。
这取决于！尝试不同的方法，看看哪种方法适合您。
【讨论】：
使用 TDD 对实际应用程序进行端到端开发确实是一项记录不足的活动。确实，您可以在那里找到大部分教科书示例、katas 和理论文章。然而，有几本书对 TDD 采取了更全面、更实用的方法——例如GOOS（强烈推荐），以及在较小程度上，Beck 的Test Driven Development by Example，尽管它们没有具体解决 RoR。
GOOS 中描述的方法从编写端到端验收测试开始（集成 测试，在您的情况下可能相当于 RSpec 测试），但在该循环中，您编写尽可能多的 TDD unit 测试您需要设计较低级别的对象。在编写这些内容时，您基本上可以从您想要的地方开始——从外层、内层或只是应用程序中对您最方便的部分。只要你模拟出任何依赖项，它们无论如何都会保持单元测试。
【讨论】：
当我开始学习 Rails 时，我也有同样的问题，有很多工具或方法可以让测试变得更好，但是在花了很多时间之后，我终于意识到你可以简单地忘记必须的规则做或不做某事，先测试您认为可能有问题的东西，然后再测试其他地方。嗯，这需要时间。
这只是我的观点。
【讨论】：