This question has, I’m sure, been asked and answered hundreds of
times, but I was unable to turn up anything in Google. Here’s the
issue: I have some code in a Rails app in the lib/ directory that
affects how views are rendered. Specifically, it checks CSS and
Javascript files for existence and some application-specific stuff,
then injects them into the right part of the HTML that’s rendered.
The question is: How to spec? I have spec’ed that the stuff that will be injected is correctly formed. However, to fully test the
code, I need to test that the stuff that is injected is there. Kind
of:
The question is: How to spec? I have spec’ed that the stuff that will be
injected is correctly formed. However, to fully test the code, I need to
test that the stuff that is injected is there. Kind of:
response.should have_tag(‘script’, /application.css/)
But there is no response object and that’s what I’m wrestling with.
I’ll betcha there’s an easy solution, but I’m not seeing it.
I’d either write a simple ‘dummy’ request (to one of your existing
controllers or make one on the fly) to catch that output, or I’d spec
it as a shared behavior and include it in my other request tests
wherever the behavior is needed. The first has better encapsulation
if you want to split that library out later as a gem or something; the
second is a little more transparent and application-focused.
This question has, I’m sure, been asked and answered hundreds of times, but
I was unable to turn up anything in Google. Here’s the issue: I have some
code in a Rails app in the lib/ directory that affects how views are
rendered. Specifically, it checks CSS and Javascript files for existence and
some application-specific stuff, then injects them into the right part of
the HTML that’s rendered.
To be honest, this smells funny to me. Why is something in lib/
affecting how views are rendered?
Or does it need to be called or “activated” by something in the
controller layer to take effect? That would make sense, but it would
be a bit tricky to spec. I’m not sure there’s enough information here
about how it functions to give a good suggestion.
Try being more specific (with us and with yourself) in describing the
behavior of the objects which do this injection. That might lead to
you to a way to test that behavior. Poor specs, as well as difficulty
in writing specs, are often the result of not clearly defining what
you want the behavior of the object to be.
To be honest, this smells funny to me. Why is something in lib/
affecting how views are rendered?
Or does it need to be called or “activated” by something in the
controller layer to take effect? That would make sense, but it would
be a bit tricky to spec. I’m not sure there’s enough information here
about how it functions to give a good suggestion.
If you already have code, posting it surely would help.
part of
Try being more specific (with us and with yourself) in describing the
behavior of the objects which do this injection. That might lead to
you to a way to test that behavior. Poor specs, as well as difficulty
in writing specs, are often the result of not clearly defining what
you want the behavior of the object to be.
By using javascript_include_local_tag in your default layout (in
the HEAD section), this will look for javascripts named for the
controller and also for controller_action
Same for stylesheets with stylesheet_link_local_tag
By using inject_javascript in a view or a controller, you can
“queue” a javascript include until render time. At render time, the
injected_javascript helper renders it wherever that appears in the
view (again, normally in the default layout’s HEAD section).
Same for CSS using inject_css and injected_css
I though I had spec’ed this by side effect, as was suggested, by just
making sure one or another of my controllers worked right. It turns
out I hadn’t gotten that quite right and I decided to dedicate a set
of specs explicitly to this instead of burying them in with other stuff.
So… the question is how to get a request object so it’s possible to
explain and then verify the behavior.
Thx,
Steve
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.