Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Unit Testing — Part 5
These libraries can be a boon for native app developers. See how they change the developer experience in the fifth part of this series.
We have learned about the store, state, Reducer and ReactiveX usage in part 4, now let’s learn about unit testing the code blocks, dive in…
Let’s start with identifying the code blocks that requires testing. To recollect, refer to the below picture of the code blocks
Should we unit test Actions?
No, these are plain classes.
Should we unit test the middleware?
Yes, but only if you decorate the data and errors that you receive from the data provider and dispatch new actions.
Should we unit test the reducers?
Yes, as they create the new states based on Actions.
Should we unit test View (Activities, Fragments or View Controllers)?
No, it should not have any work other than listening to State and responding to user events. These should be validated as UI tests.
Should we unit test the observables?
Yes, it is important we should test the subsequent actions that are employed on observables.
Should we unit test the subscriptions?
Yes, it is important we should test how subscriptions behave on success and error cases.
Now we have the understanding of the testing the needed code blocks, lets look at the testing code
Unit testing Reducers
Let’s test the authentication reducer that should change the state to show the progress bar when the LoginStartedAction is dispatched.
Though this code is trivial, in real life you may have a complex state that you are updating, it is important we should test them.
Also note — the testing class does not have any extra dependencies and mocks, it is pure JUnit testing class as the reducer is a pure function
Want to look at the all possible use cases for testing reducers — refer here
Unit Testing Middleware — Observables — Stream creators
Testing the middleware, particularly the observables, needs a little bit of mocking.
In the //Given part of the test case, we are creating a mock of the GitHubApi, called TestMockGitHubApiService that implements the interface GitHubApi .We are overriding only the needed methods and injecting them as below
Check the complete Observerable test cases here
Unit Testing Middleware — Subscriptions — Stream consumers
Testing observers or subscriptions needs a little bit of mocking. Let’s start with defining them
If you notice the code carefully, we are testing whether the observers (aka subscriptions) are dispatching the needed actions based the logic. Want to recollect the subscription logic — refer here or here.
To test the subscription, since they dispatching an action to the store, we need to mock the state, store and the reducer.
If you look the reducer code, it merely records the action that has been passed, which is used in the assertion of the JUnit test.
I hope you are able appreciate the fact, you are able to test the code blocks with out any Android or iOS intricacies like context. By this time, you may have realised how powerful is these libraries— it helps you unit test the app piece by piece, without hardwiring dependencies. Check the complete Reducer test class here.
In the next post…
We will discuss unit testing the router.
Links to the series
Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Reactive Programming — Part 4 ⬅ PREVIOUS
