The revelation came when I was adding a scheduler to the chatbot: What if I remove the hardcoding on the synchronization primitives? That worked right away, and as a bonus, it fixed all the unexplained problems I had with tests. It is interesting to see how a sudden flash of insight impacts the thought process and changes how code is written.
As shown in the article last week, we start from the main process, beginning with the setup of a ProcessPoolExecutor. All the synchronization primitives are sent individually to the run() function this time, given the simplified scope of this article. The setup for the FastAPI web module handles receiving a batch of data.
The background processing module was very basic, mostly just a proof-of-concept. Comparing the tests for the FastAPI application and the background module, the benefit is more apparent in the latter case. With the explicit passing of the queue object as an argument, there’s no more guesswork on which queue to patch in test.
Plus, as we are ensuring both the test and application are referring to the same queue now, we can pass real data into test, and ensure they are being received properly. Documenting the insight into blog posts can be seen as my attempt to think out loud. Perhaps we can go through the process of adapting it to our setup in a more generalized form in a future article.
#Python #FastAPI #AsynchronousProgramming #SoftwareArchitecture #UnitTesting #opentowork #fedihire #getfedihired
