Hi everyone, using Orbit's testing framework, is there a way to ensure that no more states/effects a...

# orbit-mvi

[Benoît]

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

[Mikolaj Leszczynski]

By default, only the first intent is executed (so called flow isolation)

[Mikolaj Leszczynski]

does that help?

[Mikolaj Leszczynski]

other than that, there’s no such functionality

[Mikolaj Leszczynski]

could you elaborate on your use case?

[Benoît]

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

[Mikolaj Leszczynski]

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.

[Mikolaj Leszczynski]

we consider extra states being emitted as an indication of an issue and fail the test.

[Mikolaj Leszczynski]

means either your test or your code is wrong so we are very strict here for safety.

[Benoît]

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?

[Mikolaj Leszczynski]

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

[Mikolaj Leszczynski]

we can always reconsider if given good arguments 🙂

[Mikolaj Leszczynski]

I feel erring on the side of caution in this case is better, it doesn’t really have drawbacks beyond (to my knowledge) a minor inconvenience of having to write all states - whereas the opposite approach might miss genuine bugs

[Benoît]

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"

[Benoît]

It would allow for writing shorter tests when desired, if explicitly specified

[Mikolaj Leszczynski]

if there’s a genuine need for this we’ll consider 🙂

“Premature optimisation is the root of all evil” and all that

[Benoît]

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

[Benoît]

I agree with this statement, when it comes to optimisation. But when it comes to an API being advertised as "extensible" things are different

[Mikolaj Leszczynski]

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

[Benoît]

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

[Benoît]

And thank you for your help!

[Benoît]

@Mikolaj Leszczynski I've got one more question regarding testing actually 😄 Is there a way to assert the following:
• State 1 emitted
• Effect 1 emitted
• State 2 emitted
• Effect 2 emitted
In this exact order?

[Mikolaj Leszczynski]

not currently

[Benoît]

okay thanks

[Mikolaj Leszczynski]

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

[Mikolaj Leszczynski]

obvs no way to ensure order in non-blocking

[Mikolaj Leszczynski]

but since we’re now running this suspending - perhaps it’s a good idea to make it so?

[Mikolaj Leszczynski]

it becomes tricky when effects are e.g. posted from parallel coroutines launched from the intent 🤔

[Benoît]

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

[Benoît]

I'd say if effects are posted from parallel coroutines it means you don't really care about the ordering

[Benoît]

I mean there's no way to ensure order when coroutines are run in parallel

[Mikolaj Leszczynski]

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

[Mikolaj Leszczynski]

thanks @Benoît I think this makes a lot of sense. I will create a ticket so we can track this - unfortunately this would mean a breaking change to the testing API so slating this for a 5.0 milestone 😉

[Benoît]

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.

[Benoît]

Hmm would it have to be a breaking change? Should be relatively easy to add another way of testing without breaking the old one, no? I'm not sure I haven't dove into the internals of the testing lib much

[Mikolaj Leszczynski]

we could add an alternative testing API I guess

[Mikolaj Leszczynski]

and deprecate the old one

[Mikolaj Leszczynski]

I’ll see how this looks

[Benoît]

That's probably a better option indeed, if possible

[Benoît]

shout out if you need some help doing this, I'd happily contribute