carlosplusplus

Thank you for your comment and question, danso.

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!

Thank you, lukes386, for your comment.

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.

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.