So all you’re doing is setting the cached instance variable to the environment you want.
Follow Up (June 20, 2011)
So two distinct issue have come up as a result of the above content.
Firstly, there was no ensure meaning that if an exception was raised in the middle of the stub then the environment would be changed for the remaining tests. This was a stupid mistake but, it happens, so I’ve updated the gist and my code.
Secondly, the issue of checking environment in code. The solution for this would be to have a constant in each env file that defines whatever it is you are using the env check for. So in the example I was working with each env file would have a EMAIL_TARGET constant.
You still need to test this, so the stub provided is still useful in this regard.
The only problem I encountered is that including Compass in the previously detailed way does not include any of the Sass Extensions. They’re written in Ruby, so just setting a SASS load path isn’t sufficient.
Update: see my updated post with details of a newer, better solution.
If you’re like me, you’re probably already playing around with the Rails 3.1 release candidate. If not, go take a peek at why you should be excited. (Thanks Ryan Bates!) If so, like me, you’re probably also wanting to play with all your old friends, like Compass.
Compass, by default, manages SASS for you. It gives you a place to put it, app/stylesheets, and takes care of bundling everything together. The new Rails 3.1 asset pipeline does this all for you using Sprockets instead, and does it nice and cleanly in a consistent manner with CoffeeScript and whatever else you might eventually integrate.
The problem is, I don’t want Compass managing my SASS. I like love the asset pipeline. But by default, from the asset pipeline I can’t use Compass. It doesn’t know what or where it is. So, I’ve added this to my new rails 3.1 projects:
I’m also a heathen and like SASS, not SCSS, and it took me a minute to realise that it’s just as easy to use. Instead of mystyle.css.scss, name your stylesheet mystyle.css.sass. To make rails do this by default when you’re generating controllers et al, add this into your config/application.rb‘s config section:
You can even rename the default application.css to application.css.sass and all the sprockets require_* machinery still works. Make sure you change the /* ... */ comments to // comments.
I was part-way through submitting an answer on Stack Overflow when the initial question was deleted. The developer was having an issue with Rails thinking that the singular of “faxes” was “faxis” when in fact it should be “fax”.
I thought it was an interesting problem, so here’s the answer I prepared:
You can overwrite or set Rails’ singularizations and pluralizations (properly called inflections) in config/initializers/inflections.rb
As you can see below, Rails now understands how to count “faxes” correctly. One fax, two faxes, three faxes, and so on. You can test that from within the Rails console:
We use Cucumber-Nagios at The Frontier Group to monitor live web applications and web sites. It’s the natural extension to the integration testing we conduct on our applicaitons as we develop them, and it gives us a deeper insight into an applications real-time availability and responsiveness… or so I thought.
Due to an oversight on my part, the Cucumber feature that we use to search this blog was failing “in real life” but passing according to Cucumber-Nagios. I was searching for a text string that should have appeared only after conducting a successful search of the articles, however it was also appearing in the list of popular articles on the sidebar. Whoops!
After the test started failing for real, because the blog post was no longer referenced in the sidebar, I dug deeper in an attempt to find the problem.
In the end Aaron did most of the hard work, and tracked the problem down to webrat not submitting the form properly. As such the response data that was being parsed was incorrect.
The trick that we used (and it is a nasty hack, to be sure) is to fool webrat into operating in “Rails mode”, whereby it POSTs the form properly. I added the last four lines to features/support/env.rb and it’s done the trick.
So if you’re having a problem with webrat posting data, maybe this will help you. Alternatively, if you have a suggestion on how this could be fixed in a cleaner way, please leave a comment.