0

I'm writing an app that responds to a webhook event that then kicks off a few background jobs using Sidekiq. I'm using Minitest for my testing library.

Right now I have one large integration test (/test/integration/test-name.rb). I know integration tests are typically reserved for testing end-to-end functionality of controllers. But the way my app works is: I have a create method inside of my controller which is the entrypoint for incoming webhook events. These webhook events are then handled by a Sidekiq job, and the Sidekiq job determines whether the event should be saved to the database.

As a result it feels like an integration test is the right place for testing this end-to-end flow: a third-party services kicks-off a webhook event, user visits application, Sidekiq handles webhook event, and the user sees the job data render in HTML.

But my question is: is this the right place for testing key application functionality, i.e. my Sidekiq worker classes? Should I be writing their tests elsewhere?

Within my integration test I'm also calling to external HTTPS service, for which I'm encapsulating with the VCR gem.

eighdah14
  • 155
  • 6

1 Answers1

0

Integration tests are slow because they run through the entire stack and do not mock anything. Hence testing all scenarios makes the test suite slower. Unit tests on the other hand are super fast. Hence the general idea is to test all possible cases (including all error cases) in unit tests, and then test only the success case and maybe 1 failure case in the integration tests. The testing pyramid sums up this idea quite well.

For arranging your tests, assuming you have app/workers/*_worker.rb you could have test/workers/*_worker_spec.rb - test all possible scenarios here. And then have minimal tests in test/integration with the intention to just check if the worker is being called properly. For testing Sidekiq you can refer to the official wiki or my blog.

tejasbubane
  • 914
  • 1
  • 8
  • 11