We learned how to test containers and I mentioned that the important part is that you don't test the connection
to redux,
how do you test redux then, do you test it at all?
The answer is yes we test it but we have to be careful about what we test.
We probably don't want to test very complex chains of actions and reducers and state, in the end the
reducers are the meat we want to test especially if we follow the pattern of not putting too much
logic in the action creators. Then testing reducers is super simple,
there's synchronous so we don't have to deal with async code and there are just functions,
we pass something in,
we get something out like for example for authentication,
let's say we want to write a test for this.
So add an auth.test.js file, here we don't even need enzyme because we're not testing any react
components,
we don't need to render anything, we just test normal javascript code, we test functions, the reducer function.
So what I just do here is in the test file, I first of all import the reducer function from ./auth.js
in this file, in this case like that
and now I also need to import the action types so as action types, I import everything from ./actions
action types
and now we just write the test.
So again we have describe,
I now give this a clear description we can see in the console like the auth reducer
and then in the function here, we can write the many tests we have.
Obviously we can again use beforeEach to do some general configuration if we need to
but I want you to start right with the tests,
so it
and now let's see what we test, let's for example test that we get the right initial state if we actually
pass an invalid action type to it,
so it should return the initial state,
could be the description here.
And then I pass my javascript function and in there, I now expect my reducer
if I execute it
so now inside expect, I simply execute the code I want to test, just as before with wrapper but now with
a normal javascript function and it will actually pass undefined here as an initial state, that is the
case when the state is just getting set up at the beginning of our app and the action is just an empty object,
so no specific action.
So in this case I expect my state to equal
and now it should equal my initial state defined in the reducer function of course
so this javascript object,
that is exactly what I test for,
it should equal that object.
Now if we save that file, this should be executed too,
and it is auth.test.js is executed
so there, we now see that that is successful and this is how easy you can test a reducer. Of course
you can also test for specific cases, so we can write another test where it should store the token
upon login
and now in this function here, I actually expect to execute a reducer function with let's say the initial
state and we could set this up in beforeEach.
So I
execute the reducer function with the initial state and with an action where the type is actionTypes.AUTH_SUCCESS
and now of course we need to pass the correct payload with that action here too,
so not only the type but also the payload of that action
and we can see that payload of course in our action creators file. In AUTH_SUCCESS, we also pass
ID token and user id, so that is something we should pass on here
too, and that could be some token, the exact value of course doesnt matter for the test and some user ID.
Now that is the reducer function, how we execute it.
Now we expect it to spit out an updated state which respects this token and user id, so the updated
state should equal our initial state in general but the token of course should be some token and here,
that has to be the exact value here, if it weren't then something would be wrong inside our reducer,
that's the idea behind testing,
the user ID should therefore be some user ID.
Now if we save this, this also passes and as soon as I change the expected value to some user, it fails
because now we have differing values.
So this is how we can also test reducers, they are pure functions and therefore very simple to test.