我什么时候应该在 Cucumber 和 Cucumber 中单独测试视图？ RSpec 工作流程？

发布于 2024-10-07 23:37:01 字数 537 浏览 0 评论 0原文

经过一段时间的黄瓜和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

，还是应该测试更复杂的视图？

原文

After some time of doing Cucumber & RSpec BDD, I realized that many of my Cucumber features are just higher level view tests.

When I start writing my scenario and then go down to RSpec, I don't ever write view specs, since I could just copy and paste part of the scenario, which would be ugly dupliacation.

Take this scenario for example

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"

I know that this isn't directly testing the view, but writing separate view spec to check for the same thing seems redundant to me.

Am I approaching Cucumber wrong? What exactly should I test in view specs?

Should I write them for every single view, for example testing views for actions like

def show
  @project = current_user.projects.first
end

or should I just test more complex views?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不美如何 2024-10-14 23:37:01

这是一种被广泛接受的（在我看来，不正确的）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：查看规范用于与其他开发人员传达合同，应谨慎使用（但尽管如此应该使用）。

It's a widely-accepted (and in my opinion, incorrect) Cucumber philosophy that views should never be tested within RSpec. The argument goes that since the behavior of the view can be described in Cucumber, RSpec should stick to what it knows best -- Models and Controllers.

I argue that the "human-readable" aspect of Cucumber makes some aspects of view-speccing important. For instance, I find view specs to work very well when working in parallel with a front-end developer. If a JavaScript developer knows that he'll want to hook into a selector on your page, it's important that your view provides that selector.

For example:

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

Note that the specs do not describe the content, they are willfully brief, and they do not describe interaction behaviors. Because the view is the portion of your application that will change the most, view specs should be used sparingly.

tl;dr: View specs are for communicating a contract to other developers and should be used sparingly (but nonetheless should be used).

回复收藏 0 原文