测试基本(抽象)控制器 [英] Test a base (abstract) controller

查看:137
本文介绍了测试基本(抽象)控制器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个基本控制器有一些功能,基本控制器不能从外部访问,没有路由匹配。

I have a base controller with some functionality, that base controller is not accessible from the outside, no route matches it.

然后,我扩展控制器与其他控制器添加额外的功能和路由,我有3个控制器扩展基础控制器只是为其中每一个定义3个方法。

Then, I extend that controller with other controllers to add extra functionality and with routes, I have 3 controllers extending that base controller just to define 3 methods on each one of them.

我想测试基本控制器,但我不能做

I want to test the base controller, but I can't do

post :index

因为没有路由(无路由匹配错误)

because there are no routes for that action (No route matches error)

我不想添加测试这3个控制器之一,因为它们改变了很多(控制器在... 3周的活动期间使用,然后删除)。

I don't want to add those test to one of those 3 controllers because they change a lot (the controller is used during a campaign of... 3 weeks and then deleted).

一些代码.. 。:

基本控制器CampaignController

The base controller, CampaignController

class CampaignController < ApplicationController
  def index
    #some code...
  end

  def campaign_name
    raise('campaign_name missing')
  end

  def campaign_url
    raise('campaign_url missing')
  end

  #more actions....

end

其中一个可访问控制器,SchoolCampaignController

One of the accesible controllers, SchoolCampaignController

class SchoolCampaignController < CampaignController
  def campaign_name
    'school'
  end

  def campaign_url
    school_url
  end
end

这些控制器基本上是,但有时我需要重写一个基本操作

those controllers are basically that but sometimes I need to override one of the base actions

那么,我做错了什么?如何正确测试CampaignController?

So, what am I doing wrong? how can I properly test CampaignController?

编辑:我不想测试这两个方法引发错误,我想测试索引为例,其他操作(未显示)

I don't want to test those two methods that raise an error, I want to test index for example, or some of the other actions (not shown)

我尝试过response = controller.index,但它不调用before过滤器,响应不是http响应,它只是该命令的输出(我不能做预期像... response.should render_template(xxxx))

I've tried with "response = controller.index" but it doesn't call the before filters and the response is not an http response, it's just the output of that command (I can't do expectations like... response.should render_template(xxxx) with that)

编辑2:绕过路由错误我在一个before(:all)块中的测试中创建了路由,然后路由不是一个问题,但现在,我得到关于非现有视图的错误(每个可访问控制器实现所有视图,但抽象一个有非)

EDIT 2: To bypass the routing error I've created the routes inside the test in a before(:all) block, then the routing is not a problem, but now, I get errors about non existing views (each accesible controller implements all views, but the abstract one have non)

推荐答案

我想你打算测试 assigns session db 更改,而不是渲染视图。您可以为抽象控制器重新绘制路线,仅供测试( https://gist.github上有一个示例) .com / zilkey / 543300 )。

I guess you're planning to test the assigns, session and db changes then, rather than the rendered view. You can redraw routes for your abstract controller, for testing purposes only (there's an example at https://gist.github.com/zilkey/543300).

为了解决没有渲染视图的问题,我建议你围绕每个 get post put c>一个块从无视图发现的错误(我会写一个小助手函数来做这个)。如果您的控制器将视图呈现为最后一步,您仍然可以检查分配,会话和数据库更改。

To get round the problem of no view being rendered, I suggest you surround each get, post, put or delete with a block that rescues from the no-view-found error (I'd write a small helper function to do this). Provided your controller renders the view as its last step, you should still be able to check the assignments, session and db changes.

另一种方法是将测试写入用于抽象控制器的特定实例,并将控制器名称和所需的任何数据计算出来。这样,您就不会遇到对非功能控制器进行功能测试的问题,并且您可以每3周轻松地重写测试。

An alternative would be to write your tests to be for a specific instance of the abstract controller, and factor out the controller name and any data needed. That way you don't have the problems of functional testing against a non-functioning controller, and you keep it easy to rewrite your tests every 3 weeks.

这篇关于测试基本(抽象)控制器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆