In my company’s code base, there are lots of places where models call tasks and tasks turn right around and call model methods and vice-versa, yet we still have them separated out into the models module and tasks module in an app. Is this good practice? We are dangerously close to creating circular dependencies, and that seems like a code smell to me. One thought I’m chewing on is maybe tasks can only call into models and models can’t call into tasks. You never see a model directly call a view (besides using reverse). What are your thoughts? Also, do you stand up a celery process when running unit tests?
Hey there!
Here’s my opinion on these:
About the calling hierarchy, this totally depends upon the implementation.
I tend to use the hack software style guide, it’s really useful, i’ve been using some of the strategies on it and adapting others, but i think the most valuable one is the services.
About testing in celery, normally i mock the apply_async method, because most of the time i don’t want for the task to be executed, i just want to check if that function is dispatching a task. But if you really to test end-to-end you will probably need to setup a worker, or use the always_eager setting (that calls the function on the same thread instead of dispatching it).
Hello and thanks for the reply! I have heard that it is better to stick to fat models than to add a service layer, and I don’t think that my team would go for it. I am glad that it is working for you though!