What I like to do with rake tests and/or delayed jobs is write the actual business logic in some other file / module: a module in lib/, a DCI style class, whatever. Then the delayed job / rake task just calls that code.
So your rake / Delayed Job interface is one, maybe two lines. And the body of your code lives somewhere easily testable with standard unit tests without having to mock out Rake (and/or forcing your asnyc queue mechanism to be synchronous for testing).
Thank you for the great comment & suggestion, rpwilcox!
As you recommended, I'll be moving the majority of my actual rake task into a DelayedJob which will perform all the work. The rake task will then only be responsible for queueing up the batches of work and nothing else. And yes, at that point, I could just test the DelayedJob itself vs. the actual execution of the rake task, as I'd have a high degree of confidence that if the DelayedJob works on a model as expected, it will work via DelayedJob in batches.
I decided to write about this first to showcase the capability of explicitly testing rake tasks - I started learning Ruby / Rails about 6 months ago and wanted to share this knowledge. My follow-up post will be on turning this into a DelayedJob.
What I like to do with rake tests and/or delayed jobs is write the actual business logic in some other file / module: a module in lib/, a DCI style class, whatever. Then the delayed job / rake task just calls that code.
So your rake / Delayed Job interface is one, maybe two lines. And the body of your code lives somewhere easily testable with standard unit tests without having to mock out Rake (and/or forcing your asnyc queue mechanism to be synchronous for testing).