How to approach TDD when writing React/Redux

Question

I am writing an React/Redux application, using TDD. The question is how to approach the first steps in writing a new applications, given all the boilerplate I want to use.

According to TDD, I should write only the minimal code in order to pass my test, and only then refactor. Should I start without Redux, for example, and then refactor and introduce Redux? I will have pretty big refactoring, considering Redux' boilerplate (stores/reducers/wrapper elements etc.)

I understand the huge advantages of the TDD approach. The question is if a better approach will be to be "allowed" to use more than the minimum set of code to pass a test, in those cases..

Answer 1

Redux won't interfere with your ability to write the minimal code to pass each individual test.

Your individual React components are just taking props and doing/displaying something. Your unit tests for those components shouldn't care whether those props are passed in the standard React way, or inserted via react-redux. So the presence of Redux won't affect your ability to pass React component tests with minimal code.

There are some minor exceptions, such as moving component state into Redux state, or changing the way side effects (e.g. fetching data from an API) are handled. Those types of changes may require some changes to your tests, but they will likely make them simpler, if anything.

Of course if you add Redux, you will have to write tests for the new Redux reducers/action creators/selectors, etc., but writing those tests is super straight-forward. You're not going to be duplicating any work: the amount of time you spend writing tests will be about the same regardless of whether you start with or without Redux.

As for the general concept of starting with or without Redux: Dan Abramov, who created Redux, recommends starting with plain React and then only adding Redux down the road if you find that you need it.