0
votes

I want to test a destroy action that I know to be working, but I want a test for it.

It is a destroy action. The route: DELETE /journals/:id(.:format) journals#destroy

In the admin/journals.rb registration block have a controller block to override the destroy method.

ActiveAdmin.register Journal do
  controller do 
    def destroy
      # do stuff and redirect. 
    end 
  end
end

My test

require 'rails_helper'
RSpec.describe JournalsController, type: :controller do

  let!(:journal) { Journal.create(title: 'Title1') }

  it 'sets the out_of_stock attribute to true' do

    expect {
     delete :destroy, params: { id: journal.id }
   }.to change { journal.reload.out_of_stock }.from(false).to(true)

  end
end

For some reason this does not hit the method, nor does it pass.

Result

1) JournalsController destroy journal is in stock and receives destroy sets the out_of_stock attribute to true
 Failure/Error:
   expect {
     delete :destroy, params: { id: journal.id }
   }.to change { journal.reload.out_of_stock }.from(false).to(true)

   expected `journal.reload.out_of_stock` to have changed from false to true, but did not change
 # ./spec/controllers/journals_controller_spec.rb:15:in `block (4 levels) in <top (required)>'

If I override #show in the same manner and call it from a spec with get :show, params: {id: journal.id } it does hit the action inside the registration block.

I have tried other text book examples of controller transactions like creating a user, but it just doesn't work.

I do however have an api namespace where tests pass. It only calls get :index though.

Is there some special AA rspec settings that I don't have? Maybe in spec_helper/rails_helper.

How do I make my test hit my action?

Any help is appreciated.

1
It does hit the destroy action. Only the param `out_of_stock' is not changed as expected in the test case @VeryPoliteNerd. - Aarthi
You can see the test application logs to check how the request is processing. - Aarthi
@Aarthi. I really don't think it does. I printed text and even raised exceptions in the method to see if it was hit. When I did the same thing the show action i got the output when running the test. I didn't in the destroy case, but calling the action from the GUI like normal did produce the expected output - printed strings and raised exceptions. - VeryPoliteNerd
I figured it out. The test got caught in a check_permission hook and got redirected. Exactly the behaviour I want, but not what I was testing. Oh well. Thanks! @Aarthi - VeryPoliteNerd

1 Answers

0
votes

It turns out I hadn't taken some permission checks into account and the test got redirected. Setting up a current_user with the correct role (in my case) fixed the issue. The destroy action was ultimately called.