I had a quick peek, and the deprecation warning is caused by the setup order in your test fixtures.
An aiohttp app has two phases in its lifecycle: setup, and running.
During the synchronous setup phases, the
app object is created and all
setup() functions are called. REST endpoints and service features are registered here.
After that setup phase is done, the app is started and bound to an endpoint. At this point the asyncio
loop.run_until_complete() function is called.
In a production environment, this happens in
brewblox_service.service.run_app(app). During tests, this happens in the
client fixture defined in
In your test code, your
app fixture depends on the
client fixture, meaning your service is started, and then registers more functionality.
A side effect of this is that the prepare()/run() functions of your broadcaster are not called automatically.
This can be useful for test code, so you may well choose to not call setup() in your tests, but explicitly create the Broadcaster class.
Typically, we have test functions depend on only
app if they test setup-phase code, and on
client both if they test runtime-phase code.
Writing this, I do realise that the full init/setup model for services could use some more documentation. It works quite well, but requires an understanding of how concepts from asyncio, aiohttp, and brewblox-service all interact.
Version 0.29 for brewblox-service introduced the option to not bind to any port (if you don’t have a REST API, but still want to use the other scaffolding), and version 0.30 added support for MQTT will messages. Boilerplate will get a dependency version bump the next time there’s a relevant change.
I’m not sure whether you’re referring to processes, tooling, urls, or something else entirely here.
We have no formal documentation for use cases in our design process. BrewPi has a dev team of two, and we’re only now slowing down our iterative approach to development. We may revisit the decision in the future, but so far formal up-front documentation for features turned out to be write-only documents that were outdated before the ink was dry.
Design decisions are explicitly treated as snapshots, and can be found here. They help us keep track of why we started/stopped doing things.