carlosplusplus

The particular re-calculation method I presented in this blog post is (hopefully) only going to be run one time, as it serves to recalculate fields based on a database migration. Those fields are counter caches in my Rails models, meaning that their values get +1 automatically when an Answer is generated for a particular Question (approved or not).

Given the nature of the task at hand, I felt it was better practice to keep the model 'clean' and abstract the computation to the rake task itself. The computation will soon be extracted out to a DelayedJob, further isolating the re-calculation method in a modular fashion.

Hope that answers your question!

I'm new to Ruby / Rails and using RSpec in general, so I really appreciate any resources people pass along. I'll be sure to check out that talk and may refactor my tests accordingly.

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.