Architecture effect on testability

[btford]

Still digging in here, but AFAIK, none of these examples include tests. In exploring various redux strategies one thing I noticed is most of the action creator patterns tend to hide application logic in surprising ways.

One reason Elm shines is that it treats side effects as a function of the "update" function (reducer). This makes it easy to test application behaviour because none of it is hidden outside "update."

Testing "sagas" or action creators with thunks usually involves ugly strategies like hijacking the module loader to provide API compatible mocks. Although this strategy works, it doesn't generalize well. You need a new API-compatible mock for every single module you include from action creators that produces side effects.

Compare to Elm where you merely assert the shape of tasks which result from invoking your update. Tasks produce messages, which also go through the update. Thus you have no additional work you need to do for testing.

[slorber]

@btford you should take a deeper look at redux-saga because it permits to easily test complex workflows. Like Elm, the effect of redux-saga is data. Testability was a main focus of the Yassine the author, and many people love redux-saga because it's much more testable than thunks

That's right that this repo should also show how code can easily be tested

[xogeny]

I find the ideas from Elm, Redux, MobX, etc. quite interesting. I wrote up a couple of articles related to my experience with Redux. The main article talks about my concerns around testing and typing. I wrote one article dedicated to just the idea of how to integrate application logic.

I was mainly interested (in those articles) with Elm/Redux like approaches. I really had not had much exposure to MobX at that point. Interestingly, it seems that "reactions" in MobX are similar to what I had terms "reactors" in that last article. In any case, if you are interested in these topics, you may (or may not) be interested in those articles.