https://kotlinlang.org logo
Title
b

Benoît

11/16/2021, 10:22 AM
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
m

Mikolaj Leszczynski

11/16/2021, 10:25 AM
By default, only the first
intent
is executed (so called flow isolation)
does that help?
other than that, there’s no such functionality
could you elaborate on your use case?
b

Benoît

11/16/2021, 10:47 AM
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
m

Mikolaj Leszczynski

11/16/2021, 10:48 AM
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.
we consider extra states being emitted as an indication of an issue and fail the test.
means either your test or your code is wrong so we are very strict here for safety.
b

Benoît

11/16/2021, 10:53 AM
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?
m

Mikolaj Leszczynski

11/16/2021, 11:02 AM
being explicit is a design decision - I feel that the test is otherwise incomplete and opens the door to unexpected consequences.
we can always reconsider if given good arguments 🙂
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
b

Benoît

11/16/2021, 11:06 AM
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"
It would allow for writing shorter tests when desired, if explicitly specified
m

Mikolaj Leszczynski

11/16/2021, 11:08 AM
if there’s a genuine need for this we’ll consider 🙂 “Premature optimisation is the root of all evil” and all that
b

Benoît

11/16/2021, 11:09 AM
For example, I often write tests that only check the beginning of a function, and others test the end of it
I agree with this statement, when it comes to optimisation. But when it comes to an API being advertised as "extensible" things are different
m

Mikolaj Leszczynski

11/16/2021, 11:13 AM
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
b

Benoît

11/16/2021, 11:14 AM
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
And thank you for your help!
👍 1
@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?
m

Mikolaj Leszczynski

11/16/2021, 1:20 PM
not currently
b

Benoît

11/16/2021, 1:20 PM
okay thanks
m

Mikolaj Leszczynski

11/16/2021, 1:20 PM
originally we made it work in both a non-blocking and blocking mode
obvs no way to ensure order in non-blocking
but since we’re now running this suspending - perhaps it’s a good idea to make it so?
it becomes tricky when effects are e.g. posted from parallel coroutines launched from the intent 🤔
b

Benoît

11/16/2021, 1:24 PM
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
I'd say if effects are posted from parallel coroutines it means you don't really care about the ordering
I mean there's no way to ensure order when coroutines are run in parallel
m

Mikolaj Leszczynski

11/16/2021, 1:27 PM
got it so maybe we need a way to turn off strict ordering for effects in cases like this
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 😉
b

Benoît

11/16/2021, 1:29 PM
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.
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
m

Mikolaj Leszczynski

11/16/2021, 1:31 PM
we could add an alternative testing API I guess
and deprecate the old one
I’ll see how this looks
b

Benoît

11/16/2021, 1:31 PM
That's probably a better option indeed, if possible
shout out if you need some help doing this, I'd happily contribute
👍 1