Below is one approach to increasing test coverage for your cancel_product method. The key idea is that rather than stubbing out cancel_product (which prevents its code from executing), you “drive” the whole cancel action with appropriate inputs so that cancel_product actually runs. In other words, test cancel_product by simulating a real request to cancel, so you force it to execute every branch (or at least the ones you need).

Below is an example using RSpec controller tests. (A similar approach applies for Rails’ built-in functional tests.) Notice that we construct an OrderProduct and any associated objects. We then make the request with params that cause the elsif branch to run. Finally, we assert on the JSON response and the changes that were made. You may need to adjust the setup according to your factories and callback expectations.

For example:

---

spec/controllers/orders_controller_spec.rb

require "rails_helper"

RSpec.describe OrdersController, type: :controller do
describe "PATCH #cancel" do
let(:merchant) { create(:merchant) }
let(:customer_account) { create(:customer_account) }
let(:user) do
# Depending on what role you want to test,
# you might use traits like :customer or :business.
create(:user, role: role)
end
let(:role) { create(:role, name: "Customer") }
let(:order) do
create(:order, merchant_id: merchant.id, customer_account_id: customer_account.id)
end
let(:order_product) do
# Make sure your factory creates an associated appointment too.
create(:order_product, order: order, product_status: "pending", is_refunded: false)
end

before do
  # sign in if authentication is required
  allow(controller).to receive(:current_user).and_return(user)
  # Set up a dummy appointment record associated with order_product.
  create(:appointment, product_id: order_product.id, status: "scheduled")
end

context "when params[:type] == 'order_product'" do
  context "and order_product is found" do
    it "updates the order_product and appointment and returns ok" do
      patch :cancel, params: { id: order_product.id,
                                type: "order_product",
                                merchant_id: merchant.id }
      order_product.reload

      # Assumes that cancel_product should update product_status to "cancelled"
      expect(order_product.product_status).to eq("cancelled")
      # You may also want to check that cancel_product changes canceled_by correctly.
      expected_id = (user.role.name == "Customer" ? user.id : order.merchant_id)
      expect(order_product.canceled_by).to eq(expected_id)

      # Check that the appointment got updated.
      appointment = Appointment.where(product_id: order_product.id).last
      expect(appointment.status).to eq("cancelled")
      expect(appointment.canceled_by).to eq(expected_id)

      # And finally, verify the response JSON.
      json_response = JSON.parse(response.body)
      expect(response).to have_http_status(:ok)
      expect(json_response).to include("data")
    end

    it "renders not found if order_product update fails" do
      # Force update to fail
      allow_any_instance_of(OrderProduct).to receive(:update)
        .and_return(false)

      patch :cancel, params: { id: order_product.id,
                                type: "order_product",
                                merchant_id: merchant.id }

      expect(response).to have_http_status(:unprocessable_entity)
      json_response = JSON.parse(response.body)
      expect(json_response).to include("errors")
    end

    it "renders not found if appointment update fails" do
      # Force appointment update failure
      allow_any_instance_of(Appointment).to receive(:update)
        .and_return(false)

      patch :cancel, params: { id: order_product.id,
                                type: "order_product",
                                merchant_id: merchant.id }

      expect(response).to have_http_status(:unprocessable_entity)
      json_response = JSON.parse(response.body)
      expect(json_response).to include("errors")
    end

    it "calls refund_payment_for_order_product if not refunded" do
      # Here you can spy on the refund method to ensure it gets called.
      allow(controller).to receive(:refund_payment_for_order_product)
      patch :cancel, params: { id: order_product.id,
                                type: "order_product",
                                merchant_id: merchant.id }
      expect(controller).to have_received(:refund_payment_for_order_product)
    end
  end

  context "when order_product is not found" do
    it "renders an error message" do
      patch :cancel, params: { id: "nonexistent",
                                type: "order_product",
                                merchant_id: merchant.id }
      json_response = JSON.parse(response.body)
      expect(response).to have_http_status(:not_found)
      expect(json_response).to include("error")
    end
  end
end

end
end

Key Points

1. Remove Stubs for cancel_product in tests:
   In your snippet you stubbed out cancel_product to only assert that it was called. Instead, let it run so that all its code gets executed. This is what really increases your coverage.

2. Simulate different branches:
   Check for failure cases (for example, if the update on order_product or appointment fails) by stubbing those model calls to return false. Ensure you assert that the appropriate error response is rendered.

3. Test side effects:
   Since cancel_product updates records and makes calls to other methods (like refund_payment), you can use spies to verify side effects or simply check the resulting states after the request.

4. Indirect Testing:
   Remember that since cancel_product is a private method used as part of the cancel action, you should be testing it indirectly via controller tests. There is generally no need to call private methods directly in your tests.

By adjusting your tests to actually perform the cancel action with the proper parameters (and by not stubbing out the cancel_product method) you’ll see that SonarQube’s coverage improves as the body of cancel_product gets exercised.

This approach is inline with Rails’ own testing recommendations where controller actions and their associated logic (even private methods) are exercised through real requests to keep tests closer to how the app is used.