I have the test below and if there are any fixtures for this model it fails with total_unapproved and new_total being equal instead of new_total being one less.
If I remove loading the fixtures in test_helper.rb or comment them out it runs as I expect.
Here's the class function that sets approvals to true. It definitely works.
def InviteRequest.approve_invites(number)
inv_reqs = InviteRequest.where("approved = ?", false).first(number)
inv_reqs.each do |inv_req|
inv_req.approved = true
inv_req.save
inv_req.send_approved_email
end
end
Here's the test that calls the above function.
require 'test_helper'
class InviteRequestTest < ActiveSupport::TestCase
test "class method approve_invites(number) should approve 'number' InviteRequests" do
# ensure there is at least one instance
inv_req = InviteRequest.create(email: "hobojoe#test.com")
# set all InviteRequests.approved to false
InviteRequest.all.each {|r| r.approved = false; r.save}
total_unapproved = InviteRequest.where("approved = ?", false).count
Rails.logger.info "\nUnapproved Before: #{total_unapproved}"
InviteRequest.approve_invites(1)
new_total = InviteRequest.where("approved = ?", false).count
Rails.logger.info "Unapproved After: #{new_total}\n"
assert_equal total_unapproved - 1, new_total
end
end
Any idea why? I'm not using the fixtures in any other tests but maybe I will someday.
My fixtures weren't valid and changing them fixed the problem.
I'm still not exactly sure how things were failing though.
My fixtures looked like this:
one:
email: MyString
two:
email: MyString
This would fail my uniqueness validation and not save but I'm not sure why the newly created model wouldn't have 'approved' set to true and still be saved since it's correct.
Anyway, changing the fixtures to this fixed things.
one:
email: someguy#example.com
two:
email: somegirl#example.com
Maybe validation fails when you're calling InviteRequest#save? Try to replace save with save! and check to see if the test still passes.
When you use rails generator for new model, fixture file is generated as well looking like this:
one: {}
# column: value
two: {}
# column: value
When you run your tests using fixtures, rails tries to create this 2 empty records. If you have constraint in your migration (such as not null), your tests will fail for obvious reasons.
Solution:
Comment out this empty records in your fixtures files or fill them with something sensible.
Related
I'm using Rails unit testing and fixtures framework. Unless there's a configuration I haven't seen, I can't use the "Advanced Fixtures" (no id objects) from fixtures in sub-directories:
fixtures/people.yml
_fixture:
model_class: Person
myself:
first_name: Me
last_name: Myself
The following call will pass as expected:
fixtures :people
assert(people(:myself)))
while this one will not (after I move people.yml to subdir):
fixtures "subdir/people"
assert(people(:myself)))
In the later case, the error I get is this:
NoMethodError: undefined method `people'
Using Advanced Fixtures seem valuable but having all of my fixture files in the root of /fixtures seems missing something. I have a few test files and I'd like to have various tests use different fixtures directories.
Any input will be appreciated.
I would try saving people.yml in /fixtures/subdir/people.yml. The documentation is here https://apidock.com/rails/ActiveRecord/TestFixtures/ClassMethods/set_fixture_class .
test_helper.rb
set_fixture_class :people => 'Subdir::People'
in your test file.
before do
myself = subdir_people(:myself)
register(myself)
end
it "should test myself" do
assert(people(:myself)))
end
Here is my final solution:
In the fixture file, I kept:
_fixture:
model_class: Person
In the test file, I got:
def people(sym)
subdir_people(sym)
end
def test_myself
assert(people(:myself))
end
That way, it saves me from refactoring my numerous people() calls. Or I can use subdir_people() if I want.
Is it possible to modify the Rails obj?
I only want to modify it briefly and change it back.
My Reasoning:
I am trying to work on my seeds file and make it a little more robust.
In my model there is a process that looks at the current controller and the current user, it tracks this user during there session.
It throws an error though during my seed tests because there is no controller based user session.
What I wanted to do was to add
Rails.seed = true
at the start of my seed, it would get to the model and in the model I would wrap a control flow(if statement) for this property around the block that setups up tracking.
Then I would remove
Rails.seed = true
at the end of the seed file.
Instead of putting it directly on the Rails object, you can use custom configuration
config/initializers/custom_config.rb (name unimportant, just in an initializer)
Rails.configuration.seeding = false
db/seeds.rb
Rails.configuration.seeding = true
User.create
app/models/user.rb
class User < ApplicationRecord
# just as an example
after_initialize do
if Rails.configuration.seeding
puts "Seeding DB"
else
puts "Normal"
end
end
end
output
$ bin/rake db:seed
# Running via Spring preloader in process 19017
# Seeding DB
$ bin/rails c
User.create
# Normal
# => #<User ...>
I wouldn't necessarily recommend modifying the Rails class but to achieve that you could do something like:
class Rails
attr_accessor :seeding
def seeding=(bool)
#seeding = bool
end
def seeding?
#seeding ||= false
end
end
Then you could use Rails.seeding = true to set it and Rails.seeding? to access it. Also it will default to false if it is unset.
Another solution might be wrapping the part that is blowing up in a being rescue block to catch the error.
Consider the following class and methods: (This class is obviously much more complete, but for the sake of this thread...):
class Order < ActiveRecord::Base
def check
if (self.user.phone == "55555555") do
self.a_certain_method
return
end
end
def a_certain_method
# Real implementation goes here
end
end
And the following Unit Test:
describe :do_route do
it "should call a_certain_method if user phone number matches 55555555" do
# Create a user
user = Factory(:user)
# Set hard-coded phone number
user.phone = "55555555"
user.save!
# Create an order made by the ordering user
order = Factory(:order, :ordering_user => user)
# Set expectation for a "a_certain_method" call
mock(order).a_certain_method
# Call the tested method
order.check
end
end
From some reason, the above test produces an RR::Errors::TimesCalledError error, which claims that a_certain_method was called 0 times instead of 1... I've been searching around the web for a solution with no luck.
I've tried building a similiar test on a non-activerecord class, and the test produces no errors.
I've used the debugger to check that it does reach the self.a_certain_method line, and also tried using the following instead of mock(order).a_certain_method:
any_instance_of(Order) do |o|
mock(o).a_certain_method
end
Does anyone have any idea how to solve this issue since i'm kind of desperate...
I figured out what the problem was, it failed since the number was already in the database. so it failed to save the hard coded user.phone change.
Thanks for the help though :)
I'm writing an app with Rails 3. In my functional test, test/functional/cust_infos_controller_test.rb, I have these:
require 'test_helper'
class CustInfosControllerTest < ActionController::TestCase
# Replace this with your real tests.
test "should get cust" do
get :customerinfo
assert_response :success
assert_not_nil assigns("cust_infos")
end
end
My controller is fairly straightforward as it just finds all the customer's info:
class CustInfosController < ApplicationController
def customerinfo
#cust_info = CustInfo.find(:all, :order=>"cust_id")
#cust_info.each do |ci|
if ci.upload_freq == 'W'
ci.upload_freq = 'Weekly'
elsif ci.upload_freq == 'M'
ci.upload_freq = 'Monthly'
end
end
end
end
When I ran it with:
$ ruby -Itest test/functional/cust_infos_controller_test.rb
I got the following error:
Loaded suite test/functional/cust_infos_controller_test
Started
E
Finished in 0.025258 seconds.
1) Error:
test_should_get_cust(CustInfosControllerTest):
ActiveRecord::StatementInvalid: PGError: ERROR: numeric field overflow
DETAIL: A field with precision 4, scale 0 must round to an absolute value less than 10^4.
: INSERT INTO "cust_infos" ("cust_id") VALUES (298486374)
1 tests, 0 assertions, 0 failures, 1 errors
In my cust_infos table, I have cust_id as integer. But I don't know why when I ran controller test to just get some record, active record will execute insert statement. How do I fix this?
UPDATE: I commented out all the lines in customerinfo method, and run the same test. Got the exact same result. So I'm guessing it's not my methods behavior, but rather Rails? Any hint?
I see what you are trying to do. What you need to do is create a helper for your view.
application_helper.rb
def display_upload_freq(s)
case s
when 'W'
'Weekly'
when 'M'
'Monthly'
end
end
cust_info_controller.rb
class CustInfosController < ApplicationController
def customerinfo
#cust_info = CustInfo.find(:all, :order=>"cust_id")
end
end
Then in your view when your are iterating through #cust_info, for upload_freq, use dislay_upload_freq(ci.upload_freq). Assuming you have #cust_info.each do |ci|. Then you won't be confusing the db with saving anything.
Are you using factories or fixtures to create your test data? If not, how are you creating it? My guess is that the insert is happening when your test data is being set up, not because of anything happening in your controller. The second part of that guess is borne out by the fact that commenting out all code in your controller isn't getting rid of the error.
I know this post is quite old, but I will post my answer in case someone is brought here by search engines.
I had the exact same problem, the issue originates from the fixture file(s) in test/fixtures/{name_of_your_model}.yml. Rails adds some initial values in this file, in my case it looked like this:
one: {}
# column: value
#
two: {}
# column: value
and when you want to run the test, it will try to create the test database using this fixtures. And that's where the issue occurs. Trying to create an empty record while you did not allow a null ID in your table.
Deleting these fixtures, or filling them with appropriate values should solve the problem.
I have a test more or less like this:
class FormDefinitionTest < ActiveSupport::TestCase
context "a form_definition" do
setup do
#definition = SeedData.form_definition
# ...
I've purposely added a
raise "blah"
somewhere down the road and I get this error:
RuntimeError: blah
test/unit/form_definition_test.rb:79:in `__bind_1290079321_362430'
when I should be getting something along:
/Users/pupeno/projectx/db/seed/sheet_definitions.rb:17:in `sheet_definition': blah (RuntimeError)
from /Users/pupeno/projectx/db/seed/form_definitions.rb:4:in `form_definition'
from /Users/pupeno/projectx/test/unit/form_definition_test.rb:79
Any ideas what is sanitizing/destroying my backtraces? My suspicious is shoulda because the when the exception happens inside a setup or should is whet it happens.
This is a Rails 3 project, in case that's important.
That is because the shoulda method #context is generating code for you. for each #should block it generates a completely separate test for you so e.g.
class FormDefinitionTest < ActiveSupport::TestCase
context "a form_definition" do
setup do
#definition = SeedData.form_definition
end
should "verify some condition" do
assert something
end
should "verify some other condition" do
assert something_else
end
end
end
Then #should will generate two completely independent tests (for the two invocations of #should), one that executes
#definition = SeedData.form_definition
assert something
and another one that executes
#definition = SeedData.form_definition
assert something_else
It is worth noting that it does not generate one single test executing all three steps in a sequence.
These generated blocks of codes have method names like _bind_ something and the generated test have name that is a concatenation of all names of the contexts traversed to the should block plus the string provided by the should block (prefixed with "should "). There is another example in the documentation for shoulda-context.
I think this will give you the backtrace that you want. I haven't tested it, but it should work:
def exclude_backtrace_from_location(location)
begin
yeild
rescue => e
puts "Error of type #{e.class} with message: #{e.to_s}.\nBacktrace:"
back=e.backtrace
back.delete_if {|b| b~=/\A#{location}.+/}
puts back
end
end
exclude_backrace_from_location("test/unit") do
#some shoulda code that raises...
end
Have you checked config/initializers/backtrace_silencers.rb? That is the entry point to customize that behavior. With Rails.backtrace_cleaner.remove_silencers! you can cleanup the silencers stack.
More informations about ActiveSupport::BacktraceCleaner can be found here.