Hi everyone, using Orbit's testing framework, is there a way to ensure that no more states/effects are emitted? I need to make sure that my container stays in a particular state after a particular intent has been fired

By default, only the first

intent

is executed (so called flow isolation)

Basically I have an intent that does some input validation, emits a loading state, does an API call and emits a non-loading state + error/success effects/state. I wanna test that, when the input isn’t valid, the success/error state and effect aren’t emitted

if this is all in one intent you should be good! In assertions we verify there were no state changes other than the ones you declared.

Ah nice perfect! Although it would be nice to be able to control this behaviour maybe? Sometimes you just wanna check that 1 state is emitted and don’t care about what comes after?

being explicit is a design decision - I feel that the test is otherwise incomplete and opens the door to unexpected consequences.

I agree and I think such a feature should be disabled by default. The user of the API would have to explicitly say they don't want the "strict mode"

if there’s a genuine need for this we’ll consider 🙂 “Premature optimisation is the root of all evil” and all that

For example, I often write tests that only check the beginning of a function, and others test the end of it

For example, I often write tests that only check the beginning of a function, and others test the end of it

This might not be possible, as states are asserted in order - so you need to assert the first states first before asserting the last ones

Ah yeah I forgot about that, I'll probably write my own testing framework if needed then, because my needs might require too much of a change

not currently

okay thanks

originally we made it work in both a non-blocking and blocking mode

The main reason for using the testing part of the library is to test the flow (the order), you can test your reduce blocks independently, without the need for any testing framework, if your reductions are pure functions. I would really help in that regard if that type of assertions was possible

got it so maybe we need a way to turn off strict ordering for effects in cases like this

Well yeah that's another issue indeed, sometimes you don't care about the order of the effects, when they're run in parallel. Although I can't think of a reason why you'd do this, but why not.

we could add an alternative testing API I guess

That's probably a better option indeed, if possible