Is there any way to run intents multiple times in ...

# orbit-mvi

[kenkyee]

Is there any way to run intents multiple times in debug mode to verify that they don't have side effects (aka idempotent) like you can do with redux reducers or Mavericks?

[Mikolaj Leszczynski]

I suggest just unit testing them, if they produce side effects that are not declared in the assertion it should fail the test.

[kenkyee]

Then all the unit tests would have to do the run twice check probably.
Mostly curious whether it's possible since it seems to be a common thing checked for in redux/MVI frameworks...

[Mikolaj Leszczynski]

I am curious - why twice?

[Mikolaj Leszczynski]

I’m guessing by side effects you do not mean the ones you send to the view?

[kenkyee]

I think they check that reducers are "pure"

https://airbnb.io/mavericks/#/debug-checks

[kenkyee]

So this isn't running the intent handler twice but reduce {} is done twice in debug mode.

[Mikolaj Leszczynski]

I see, makes sense. We don’t currently have this, but we’ll consider building something like this in

[Mikolaj Leszczynski]

you can always wrap a unit test in repeat(5) { … } in the meantime 😅

[Mikolaj Leszczynski]

unless this relies on having the same container for both reductions

[Mikolaj Leszczynski]

also, I wonder if the idempotency check done by mavericks isn’t a fairly weak test anyway, as the reduction might appear idempotent for some input states, but not for others 🤔

[kenkyee]

I think it requires the container so that's why it's a runtime check vs. a unit test rule.

[Mikolaj Leszczynski]

unit tests run on the container as well

[Mikolaj Leszczynski]

well - in a way

[kenkyee]

True..hmm... Not sure why it couldn't be implemented as a unit test rule then 🤔

[Mikolaj Leszczynski]

testing using real world use cases and data might be one reason

[Mikolaj Leszczynski]

but this can be done in tests using fixtures

[kenkyee]

Or if people forget to do tests...

[Mikolaj Leszczynski]

“forget”