Question

经过一段时间的黄瓜和黄瓜RSpec BDD，我意识到我的许多Cucumber功能只是更高级别的视图测试。

当我开始编写我的场景然后转到RSpec时，我不会编写视图规范，因为我可以复制并粘贴部分场景，这将是难看的重复。

以此方案为例

Scenario: New user comes to the site
  Given I am not signed in
  When I go to the home page
  Then I should see "Sign up free"

我知道这不是直接测试视图，但编写单独的视图规范来检查同样的事情对我来说似乎是多余的。

我接近黄瓜错了吗？ 我应该在视图规格中测试什么？

我应该为每个视图编写它们，例如测试

等操作的视图

def show
  @project = current_user.projects.first
end

或者我应该只测试更复杂的观点？

Answer 1

这是一种被广泛接受的（在我看来，不正确的）黄瓜哲学，观点应该从不在RSpec中进行测试。该论点认为，由于视图的行为可以在Cucumber中描述，RSpec应该坚持它最熟悉的东西 - 模型和控制器。

我认为Cucumber的“人类可读”方面使得视图选择的某些方面很重要。例如，我发现在与前端开发人员并行工作时，视图规范可以很好地工作。如果JavaScript开发人员知道他想要挂钩页面上的选择器，那么您的视图提供该选择器非常重要。

例如：

describe 'gremlins/show.html.haml' do
  context 'given it is after midnight' do
    it 'has a #gremlin_warning selector' do
      Time.stub!(:now).and_return(Time.parse '2010-12-16 00:01:00')
      rendered.should have_selector '#gremlin_warning'
    end
  end

  context 'it is before midnight' do
    it 'does not have a #gremlin_warning selector' do
      Time.stub!(:now).and_return(Time.parse '2010-12-16 23:59:00')
      rendered.should_not have_selector '#gremlin_warning'
    end
  end
end

请注意，规范不描述内容，它们是故意简短的，并且它们不描述交互行为。由于视图是应用程序中将发生最大变化的部分，因此应谨慎使用视图规范。

tl; dr ：查看规范用于将合同与其他开发人员进行通信，应该谨慎使用（但仍然应该）。

Answer 2

就个人而言，我在使用Cucumber时从不使用视图规格。对我而言，验收测试更有意义，而我的复杂视图通常以Javascript为重点，无法使用视图规范进行测试。

Answer 3

不要将视图规格用于任何事情。黄瓜故事 - 甚至是RSpec集成测试 - 做得更好。 bobocopy给出的例子对于他假设的情况是很好的，但它们应该被卷入Cucumber故事/集成测试，而不是单独留下。

我什么时候应该在Cucumber＆amp; amp; RSpec工作流程？

3 个答案: