Released scenario 3.0

framework
, , ,
1

Hi there! Scenario 3.0 just released with some breaking API changes.

  • renamed state.status.application_version -> state.status.workload_version (to match what ops calls that string)
  • State.trigger is gone; use Context(...).run(State, Event) instead.

The one that’s likely to affect you the most is the second one. So after you’ve rushed to pin your dependencies, when you have five minutes to spare, come and read why we’ve broken your code.

image

The 2.0 State().trigger(...) API was based on the thought that the less imports the better, and the idea that fluent APIs are really cool (they are!). However:

  • what Boromir says
  • a fluent API goes against what Scenario stands for: one-event-per-test, one-state-per-test. However cool it is.

So your tests used to look like:

# ops-scenario>=2.0

from scenario import State
from charm import MyCharmClass

def test_foo():
    state_out = State().trigger('update-status', MyCharmClass)

Now they look like:

# ops-scenario>=3.0

from scenario import State, Context
from charm import MyCharmClass

def test_foo():
    ctx = Context(MyCharmClass)
    state_out = ctx.run('update-status', State())

This also means that instead of repeating ourselves on every trigger and pass over and over the charm type (and metadata) to scenario, we only need to set up the context once (probably in a conftest.py file) and we can re-use it again and again. The typical use case in fact is that of a single charm and context configuration.

Please share your thoughts, try it out and let us know what works for you!

2 Likes