Unexpected error from testing

34 views
Skip to first unread message

Jack Royal-Gordon

unread,
Apr 10, 2020, 4:15:33 PM4/10/20
to rs...@googlegroups.com
I have a test for a controller that receives uploaded files, and I’ve gotten past a lot of obstacles, but I’ve got one that I just can’t understand. Using RSpec 2.12, Ruby 2.0.0, Rails 3.2.21.

Code from spec/controllers/auto_controller.rb:


describe AutoController do
GoodEmails.each_with_index do | params, ix |
before(:each) do
Upload.delete_all
Log.delete_all
post :create, params
end
it "Valid posts for good email #{ix}" do
response.code.should eq "201"
Upload.count.should eq 1
Log.count.should eq 1
Log.last.message.should match(/Kobo Sales Upload/)
end
end



Some of the code from app/controllers/auto_controller.rb:

def create
begin
for i in (1 .. params[:attachments].to_i)
attachment = params["attachment#{i}"]
if attachment.present? && attachment.original_filename.is_a?(String) && attachment.original_filename.split(".").last == 'zip'
upload = Upload.create!(filename: attachment.original_filename, content: attachment.read, uploaded_at: Time.now, file_descr: params[:subject] )
Log.log_message("Sales Upload #{upload.id} received (#{params[:subject]})", distributor_id: distributor_id, task: 'auto’, data: {params: clean(params)})
end
end
render status: :created, nothing: true
rescue StandardError
render status: :created, nothing: true
Log.log_message("Bad email received; subject: #{params[:subject]}", data: {params: clean(params)})
end
end

I’m getting the test rejected message:
Failure/Error: Upload.count.should eq 1

expected: 1
got: 0

(compared using ==)


When I set a breakpoint at the end of the controller code, I see that response.code = 201, Upload.count = 1, Log.count = 1, and Log.last.message = "Kobo Sales Upload”

However, when I set a breakpoint in the spec file right inside the “it” block, I see response.code = 201, Upload.count = 0, and Log.count = 0.

My expectation was that the “before(:each)” would run before each test, so that I would see a break in the spec, then four breaks in the controller, then a break in the spec and four more breaks in the controller. Ideally, I would like to run the before code once, then perform the four tests on the result, and then iterate for the second GoodEmail. I think that I could accomplish that by using “before(:all)”, but apparently you cannot put a “post” command inside a before(:all) block, so I can’t do that.

So, I have two questions:
1) Why aren’t the database records still there when I get to the “it” block?
2) Is there a “more correct way ” (in terms of RSpec best practices) to structure this test sequence?

Jon Rowe

unread,
Apr 10, 2020, 4:39:20 PM4/10/20
to rs...@googlegroups.com
Without seeing your specific setup its pretty hard to answer the first question, the most likely scenario is you’re using transactional database tests and your webserver process is not your test process, so you’re not in the same transaction so its not the same data.

With the second question its subjective but your first problem is to get off RSpec 2.x and off Rails 3.x so I wouldn’t worry about test structure until you’re running supported versions of both.

Jon Rowe
---------------------------

Jack Royal-Gordon

unread,
Apr 10, 2020, 4:58:59 PM4/10/20
to rs...@googlegroups.com
Re: your response to my second question, it’s a chicken-and-egg thing, as I’m trying to build out my test suite prior to migrating so that I can find what gets broken by the migration. Do you think that because it’s such an old unsupported version that I’m better off migrating first and then building the test suite?

Part of the problem is figuring out what versions to migrate to, and whether to try to move incrementally to other versions along the way. But that’s a question for a different list.

--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/dejalu-217-40fcdbbc-3473-457e-9548-dcd56b32fd51%40jonrowe.co.uk.

Jon Rowe

unread,
Apr 10, 2020, 5:13:20 PM4/10/20
to rs...@googlegroups.com
RSpec wise you can upgrade to 2.99, its a fully 2.x compatible release and deprecates anything that won’t work in 3.x. Getting that “quiet” should mean you can use RSpec 3.x when you get Rails to 4.x.

Cheers
Jon Rowe
---------------------------

Philipp Pirozhkov

unread,
Apr 10, 2020, 5:14:44 PM4/10/20
to rs...@googlegroups.com
Jack,

You may update RSpec to the latest 2.99 branch which should have no differences with 2.14, but it will provide deprecation messages if it happens to notice there's something that would prevent you from updating RSpec to 3.x. Hope that helps.

You can get some inspirations on how to share the connection between web server and test process:

- Phil

Jack Royal-Gordon

unread,
Apr 10, 2020, 5:15:24 PM4/10/20
to rs...@googlegroups.com
Brilliant. I was just getting ready to ask for this information. Thanks!

--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.

Jack Royal-Gordon

unread,
Apr 10, 2020, 5:36:49 PM4/10/20
to rs...@googlegroups.com
So here’s my plan:

1) I’m on Ruby 2.0.0, Rails 3.2.21, Rspec 2.12.2
2) I’ll upgrade RSpec to 2.99, get all tests working
3) I’ll upgrade to Ruby 2.6.2, Rails 4.2.11, RSpec 3.9.0, get all tests working and build out the test suite further.
4) I’ll upgrade to Ruby 2.6.6, Rails 5.2.4.2
5) I’ll upgrade to Rails 6.0.2.2 (or whatever is then current)

I’m assuming that RSpec 3.9.0 will work with all versions of Rails from 4.2.11 on. If that is not true, can you point me at documentation that will tell me which versions of RSpec work with which Rails versions?

Joseph Haig

unread,
Apr 10, 2020, 6:00:10 PM4/10/20
to rs...@googlegroups.com
I have had to do a similar upgrade of an ancient Rails 3.2 app. Updates should certainly be done incrementally (3.2 -> 4.0 -> 4.1 -> etc) and there is a "correct" way detailed here: https://guides.rubyonrails.org/upgrading_ruby_on_rails.html

I'm afraid it is time consuming but you will encounter bigger problems if you try to skip versions. Also, I recall having problems trying to upgrade Ruby too far for some versions of Rails, although I cannot find any documentation of maximum compatible versions. I would recommend concentrating on upgrading Rails and upgrade Ruby when support for a particular version is dropped. For example, Rails 5 drops support for Ruby 2.1. Once you have upgraded Rails as far as you can then get the latest Ruby (2.7.1 or 2.6.6).

The third number in each version, for both Ruby and Rails, indicate patch releases so for example there is no real difference between Ruby 2.6.2 and 2.6.6 apart from bug fixes. When installing any version of Ruby or Rails you should always use the highest patch release number.

I hope I am not telling you things you already know but this sounds very much as though you have been handed an ancient application that you are not familiar with and no one else wants to touch and told to get on with it. Good luck!

Jack Royal-Gordon

unread,
Apr 10, 2020, 6:17:07 PM4/10/20
to rs...@googlegroups.com
Thanks, Joseph. Some I did know but was choosing to ignore (to my peril), and some I didn’t know.

Jon Rowe

unread,
Apr 11, 2020, 6:57:43 AM4/11/20
to rs...@googlegroups.com
rspec-rails 3.x does support Rails 3.2, so you could upgrade rspec all the way first if you choose to.

You will need rspec-rails 4.0 for Rails 6.0

Jon Rowe
---------------------------

Jack Royal-Gordon

unread,
Apr 11, 2020, 1:31:33 PM4/11/20
to rs...@googlegroups.com
Thanks for the info Jon. Do you think it makes more sense to go to RSpec 2.99 before going to RSpec 3.x, or just go straight to 3.x?


--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.

Jon Rowe

unread,
Apr 11, 2020, 1:36:57 PM4/11/20
to rs...@googlegroups.com
Definitely go to 2.99 first

Chris Irish

unread,
Apr 12, 2020, 12:58:47 AM4/12/20
to rspec
In addition to what Joseph said

Look into Dual Booting the app when doing large upgrade work like you are

See https://github.com/Shopify/bootboot  and the link in the README for the conference talk, really good info 

Jack Royal-Gordon

unread,
Apr 12, 2020, 3:26:16 PM4/12/20
to rs...@googlegroups.com
If by dual booting you mean being able to run in both the old and new gem environments (versions), I’ve covered that with rbenv. If you mean keeping separate source, I’ve covered that with git. Do you mean something else?

--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages