我应该何时在Cucumber和RSpec工作流程中单独测试视图？
经过一段时间的Cucumber和RSpec BDD，我意识到我的许多黄瓜function只是更高级别的视图测试。
当我开始编写我的场景然后转到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
或者我应该只测试更复杂的视图？
这是一种被广泛接受的（在我看来，不正确的）Cucumber哲学，观点永远不应该在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 ：查看规范用于将合同传达给其他开发人员，应谨慎使用（但仍应使用）。
就个人而言，我在使用Cucumber时从不使用视图规格。 对我而言，验收测试更有意义，而我的复杂视图通常以Javascript为重点，无法使用视图规范进行测试。
永远不要使用视图规范。 黄瓜故事 – 甚至是RSpec集成测试 – 做得更好。 bobocopy给出的例子对于他假设的情况是很好的，但它们应该被卷入Cucumber故事/集成测试，而不是单独留下。