Make sure that you also have your database.yml updated for the Test Database. 

Do you have skip_before_action :verify_authenticity_token in the controller that Apple is calling?

  jomaestradama  You shouldn't be bringing in the two background workers unless you have a very specific use case. However, if you're transitioning from one to the other, just keep in mind that you can have only one ActiveJob adapter enabled at a time. I don't recommend trying to switch them on the fly as the jobs are getting processed as it could end up with some really strange situations where the wrong adapter is processing a job. You can always enqueue the jobs as you normally would without ActiveJob and just queue them up as if you weren't within a Rails application. But, this kind of circles back to why have two different kinds of background workers that are performing similar functionalities. One reason for two workers would be for something that had mission critical transactions. Think of it like a banking transaction where you needed something to be queued up with a critical need for ensuring that the job did not get lost. Using DelayedJob to persist the job information in the database could be a viable use case, but the other background jobs were of much less importance so Sidekiq is used for those. 

I feel that the default conventions are sufficient in most cases. If something else is needed for a more unique use case then add just the one in.

Yea, most often when I find that something isn't working the way I expect in some kind of event listener or when we lose the context of the stimulus controller, I find that binding solves the issue.