推荐的Rails 2 app测试框架具有随机性

Question

我有一个Rails 2.3.5应用程序正在为纸牌游戏服务。我为它编写测试时有点松懈（读：我没有写过任何：尴尬:)，我现在想开始。

从阅读other questions开始，我想我可能希望使用Shoulda扩展Test :: Unit进行单元测试。

我想知道如何使用Capybara扩展RSpec进行功能测试，但是大多数用户与应用程序的交互是通过POST，我理解Capybara不会处理。

由于这是纸牌游戏，我显然需要能够控制rand;我也一定需要框架来处理Javascript。

1. Test :: Unit +是否合适？
2. 我是否认为Capybara无法处理POST？我可以解决这个问题吗？
3. 有没有比Capybara更好的选择？
4. 这些方法可以处理纸牌游戏中涉及的随机性吗？据推测，至少对于Test :: Unit，我可以在某个早期阶段调用srand来修复生成器，但我不知道这对于Capybara / RSpec /其他任何东西是否可行。
5. 有人能指出我专门处理为Rails 2.3.5设置Shoulda，Capybara和RSpec的资源吗？有点难以分辨Rails 3具体什么，什么不具备。
6. 我可以通过添加Watir / Firewatir获得任何收益吗？

我意识到上述问题是多方面的，但它们基本上归结为“这有效吗，或者你有更好的建议吗？”

Answer 1

如果大多数用户的互动是通过POST进行的，那么它是通过API进行的（而不是填写表格或其他内容）吗？

几乎任何RSpec / Shoulda / Capybara /测试单元/ Rack :: Test的组合都可以根据您的需要为您服务。他们都很有能力。但是，这些是我的建议：

• 如果您决定要通过HTML页面进行集成测试，请使用Cucumber和Capybara
• 如果您决定通过HTTP API进行集成测试，请使用RSpec和Rack :: Test
• 您可能想要伪造随机性。
• 你可能不需要Watir / Firewatir。

看起来你可以通过一些Capybara司机发出POST请求：

http://suffix.be/blog/capybara-post-requests

当Rails移动到3.0时，RSpec变为2.0，因此至少对于RSpec，你需要RSpec和RSpec Rails 1.3.2。

通过“假冒randomess”，我的意思是在您的测试中重新定义srand，以便您可以预测地运行它们。

module Kernel
  def rand
    YourApp.rand
  end
end

module MyApp
  class << self
    attr_accessor :rand
  end
end

然后，在让用户按下按钮之前，运行“当随机返回6时”这样的步骤定义，这将设置MyApp.rand = 6.