This rather large change adds a layer between the underlying (immutable) model and the application. In doing so we can avoid the use of a global state (useful for the purposes of configuring multiple models in the same application later on) and it also unlocks the ability to implement an MVC-like separation of concerns - again, the intention is that when it comes to comparisons, we will just be able to re-use our application views. I was hoping that ``cara.state`` could have been avoided in lieu of using traitlets, but unfortunately I found a number of limitations which were prohibitive for its use here. Foremost of which was the lack of first-class dataclass support and the difficulty in needing either to use instances of the model (immutable) or duplicate the model and its structure in a mutable form and use the ``traitlets.Instance`` type. Instead I opted for doing it myself - the ``cara.state`` module would make a very good standalone project in the future.
9 lines
307 B
Python
9 lines
307 B
Python
import cara.apps
|
|
|
|
|
|
def test_app():
|
|
# To start with, let's just test that the application runs. We don't try to
|
|
# do anything fancy to verify how it looks etc., we leave that for manual
|
|
# testing.
|
|
expert_app = cara.apps.ExpertApplication()
|
|
assert expert_app.model_state.room.volume == 75
|