Tester son code Redux

Il y a une jolie proposition de Erik Rasmussen pour l'organisation du code dans Redux :

I find as I am building my redux app, one piece of functionality at a time, I keep needing to add {actionTypes, actions, reducer} tuples for each use case. I have been keeping these in separate files and even separate folders, however 95% of the time, it's only one reducer/actions pair that ever needs their associated actions.

To me, it makes more sense for these pieces to be bundled together in an isolated module that is self contained, and can even be packaged easily into a library. — https://github.com/erikras/ducks-modular-redux

Une fois qu'on a compris comment organiser son code dans un seul fichier et qu'on utilise combineReducers pour organiser les différents reducers responsables des différentes propriétés de son global state, on peut tester facilement toutes les étapes de son application redux.

Comme le dit Erik, un reducer est toujours un tuple {actionTypes, actionCreators, reducer}, et il apparaît beaucoup plus intéressant de tester les éléments de ce tuple en une seule fois au lieu de se retrouver avec une organisation avec des fichiers séparés qui nous pousserait à écrire au moins deux tests :

• actionCreators : on teste si la fonction retourne bien une action avec le bon type et la bonne valeur expect(createTodo()).toBe({ type: CREATE, todo }) dans un fichier spécifique aux tests des actionCreators ;
• reducer : on teste si le reducer renvoie bien le nouvel état expect(reducer(state, { type: CREATE, todo }).toBe([todo]) dans un fichier spécifique aux reducers.

Sans parler des imports en début de fichier, on sent comme un smell.

Et cette odeur disparaît quand on applique l'organisation ducks :

Et en respectant la règle des exports de la proposition de Erik, on découvre les smell beaucoup plus facilement car cette proposition pousse à respecter SRP.