【发布时间】:2011-06-15 09:00:35
【问题描述】:
我正在尝试筛选无数的测试解决方案,我什至不确定我是否朝着正确的方向前进。故事是:我们正在运行一个 RESTful Web 服务,实现为 Rails 应用程序,它支持我们的移动客户端。我们正在对 Web 服务进行单元测试(当然),但这涉及模拟应用程序的许多部分,例如搜索堆栈 (Apache SOLR)。
此外,我们的测试不(即不能!)涵盖关键路线,例如移动登录/登录过程,因为这涉及 API 应用程序和移动网站之间的通信,用户可以在其中输入凭据,例如用于 SSO(Janrain Engage)。因此,标准的 Rails 集成测试是行不通的。
我意识到,理论上,如果测试套件设计得非常好,模拟只发生在下一层测试开始的那些连接点,然后通过单元或功能测试服务 API 和移动网站分开,一个人可以获得相同的测试覆盖率。我发现在实践中,如果您有多个开发人员独立开发测试套件,这是一种错觉。我只是承认我们的单元测试根本没有设计得那么好。特别是在练习 TDD 时,我发现虽然测试可以驱动应用程序代码,但测试代码设计仅针对被测单元量身定制,从而导致测试套件相当广泛地增长。
我发现的另一件事是,有时我们并没有纯粹使用单元测试来检测回归,例如由于连锁效应,错误的查询被发送到 SOLR 服务器。这就是为什么我认为确保整个堆栈沿着关键路线工作的唯一真正方法是在每次部署之前在暂存服务器上自动对其进行端到端测试,即将实际的 HTTP 请求发送到应用程序。
我的问题是:
- 您认为这是一个合理的做法吗?我发现关于在 Web 上端到端测试实时 API 的信息非常少,这让我想知道我是否有任何意义
- 您建议使用哪些工具/设置?我们使用 Watir 为我们的网站运行验收测试,但对于 Web 服务(不需要浏览器环境,不需要 JS 或任何类似 UI 的东西)来说,这似乎有点过头了。甚至像 Ruby 脚本这样简单的东西?
- 您可以给我的任何一般最佳实践或建议 w.r.t.设计这样的测试?
【问题讨论】:
-
我想知道 Capybara/WebRat 与 Mechanize 作为驱动的组合是否是一个不错的选择?
标签: ruby-on-rails web-services testing integration-testing acceptance-testing