I have to change my rails environment while running my tests cases.
if Rails.env.production?
# Do something
else
# Do something else
end
How do i change my rails environment in mid of tests cases.
I am using rails 2.3.16 and ruby 1.9.3
If you want to test that code you need to stub that call by doing something like this.
Rails.stub_chain(:env, :production?).and_return(true)
That will basically make any call to Rails.env.production? return true.
You didn't give much of what framework you're using to run test cases so that works in RSpec with mocks.
That will make whatever call you're doing go in to that block of code so you can write tests against it.
To test the above mention code you can change your environment as mentioned by #Leo if you ar using RSpec.
If you are using Rails built in framework to write the test cases then You can do this.
Rails.env.stubs(:production?).returns(true)
Use
Rails.env.stubs(:production?).returns(true)
if you are using rails built-in testing framework for writing your test cases.
This question is better articulated like this (see below). I tried submitting these as edits to the original question but some "smart" reviewers decided to reject my edits. Interestingly, those who rejected my edits seem to have zero experience with ruby/rails
I have to write test cases for a piece of application code which is dependent on rails environment. The code reads like this:
if Rails.env.production?
# Do something
else
# Do something else
end
How do i simulate rails environment in my test cases so that I can test both the if part and else part of the logic?
I am using rails 2.3.16 and ruby 1.9.3
Related
In a Rails app, I would like to have a setup that allows me to run fast unit tests of Rails independent application logic.
Have an alternative minimalistic test_helper.rb file where you just load minitest and make sure to require the code under test in your testcase file. That way you can run the test in isolation quickly and you can also run the test via Rake with the Rails environment loaded. See this gist for a code example.
There is explanation article about spec_helper.rb for rspec. You can use it analog for unit tests, of course.
I'm having trouble with PaperTrail (auto-versioning of objects for Rails) being used with RSpec tests. Normally I want my tests to run without PaperTrail versioning, but there are a handful of tests for which I want PaperTrail turned on. I typically run my tests with Guard and Spork, and I can use things like PaperTrail.enabled = true and PaperTrail.enabled = false around a given test and everything works fine.
However, when I run the tests with RSpec, the tests requiring PaperTrail fail. To be more specific, it appears that while code in before filters can produce versions objects, code in the tests cannot. After a considerable amount of digging and tinkering and trying code snippets (I've tried this and this), it looks like the best solution is to use the require "paper_trail/frameworks/rspec" line mentioned in the PaperTrail README.
Unfortunately, each of these keeps me right where I started—tests pass with Guard/Spork but not vanilla RSpec. This is in particular an issue because while I use Spork locally, our continous integration server runs RSpec directly.
Does anyone have any insight?
PaperTrail now has documentation on tests with vanilla rspec
https://github.com/paper-trail-gem/paper_trail#7b-rspec
After including require 'paper_trail/frameworks/rspec' in your spec/rails_helpers.rb
... PaperTrail will be turned off for all tests by default. To enable PaperTrail for a test you can either wrap the test in a with_versioning block, or pass in versioning: true option to a spec block.
Somehow my issue was fixed by changing before(:all) and after(:all) behavior to before(:each) and after(:each).
I'm working the Finance gem, and I am having an issue where some of the code fails when run inside Ruby on Rails.
I would like to test for this by running the existing test suite inside the Rails environment, however, I'm not sure how to go about this. I'm looking for something to the effect of
run_all_tests
inside_rails do
run_all_tests_again
end
inside my Rakefile, or wherever is most appropriate.
I haven't been able to find much on Google; any assistance would be much appreciated!
I find that in order to thoroughly test a Rails application with Rspec I am required to write more test code than actual functional Ruby code. Call me crazy but this does not seems right. Is there a different/alternate approach (even one that is not as comprehensive as Rspec).
For unit testing I guess you won't find any replacement.
But for integration testing, you could create scenarios within your browser thanks to Selenium. See: http://seleniumhq.org/
There are many option available here are the few list
Rspec
Watir
Cucumber
factorygirl
capybara
and many more
I have the following mocha mock that works great.
In a test.rb file:
setup do
Date.stubs(:today).returns(Date.new(2011, 7, 19))
Time.stubs(:now).returns(Time.new(2011,1,1,9,0))
end
The problem is that the timing is broken for the tests. After the tests run the date and time objects are still mocked.(!)
Finished in -21949774.01594216 seconds.
I added the following:
teardown do
Date.unstubs(:today)
Time.unstubs(:now)
end
This throws the following error for each test: WARNING: there is already a transaction in progress
Is this the proper way to unstub? Is it better to unstub at the end of the test file or even at the end of unit test suite?
Working in Rails 3.07 and Mocha 0.9.12
Thanks.
I don't know if this is fully your problem, but it is just unstub, not pluralized.
Other than that, there should be no issue. You definitely want to unstub after each test (or set of tests, if a bunch of tests need the stubbing) because once stubbed, it will stay stubbed, and that can screw up other tests.
The accepted answer is spreading misinformation and should be considered harmful.
One of the main purposes of a mocking library like Mocha is to provide automatic mock/stub teardown as part of the integration to various testing libraries. In fact if you look at the GitHub repo for Mocha you will see that significant maintenance effort is put into making Mocha work smoothly with all the versions of several different testing frameworks.
If this isn't working properly then you need to figure out why Mocha's built-in teardown isn't working. Unstubbing manually in your own teardown is just papering over the problem, and could hide subtler issues with stub leakage or Mocha otherwise misbehaving.
If I had to take a wild guess money would be on your stub somehow being run outside of an actual test because that's the most common cause I've seen for this kind of thing in the wild, but there's not enough information from the question to really ascertain.