Today I would like to talk about testing our code and what I’ve recently learned about it.
1. Layering the code
First of all, I need to raise the issue of usefulness or even necessity to split the code into layers. If you don’t do it then start from today! A good way to start is to read this article about MVP architectural pattern. What’s the other benefit from having our code decoupled except from having a clean and easy to maintain codebase? Yes, we get the possibility to test it.
An easy way to find out that someone breaks the rule of Single Responsibility Principle are classes that contains too many private methods. It’s not the only determinant but it may indicate that something went wrong there.
Imagine that we don’t have layered code and functionalities depend on each other. For example calls to an API or to a database are placed in the same class that we use to process the results and display them on the users screen. Apart from getting messy code it becomes difficult to test. Why? If the test successfulness depends on many functionalities it won’t be fast and reliable. For example, if it depends on the API calls so it also depends on your internet connection. In this situation there is no point in even running them if we don’t trust them and they aren’t consistent in returned results. If the tests are slow it discourages us from running them often.
You may say – fine, but if I have layered code and I want to test it and the tests will still use all this unreliable and slow functionalities like API calls but now they are divided into modules. And here comes mocking into play. It’s a nice solution to the problem described above. We omit the issue of necessity to care about different modules apart from the one we are testing at a given time. In this situation we can see the real beauty of interfaces. While writing a test, we can forget about the real modules and use the mocked ones implementing the same interfaces as the real ones. To illustrate, lets see some examples of testing the presenter from my music app that I’m currently working on. We will take a look at three approaches, the last one is using Mockito – mocking framework. It’s worth to mention that well known Uncle Bob prefers to write his own mock to reduce the number of languages in his projects as he stated in this article but when you consider the time spent on writing your own mocks you may not agree with him.
3. Testing the presenter – first approach using flags
In this approach we set flag to control what songs repository should return. We test two cases, when songs were found view should display them, second case when no songs were found.
4. Testing the presenter – second approach using anonymous classes
Advantage of this approach is readability but if we have more methods in the interface we will have to implement all methods in anonymous class even if we are not testing them so the test may become very long and not so easy to read.
5. Testing the presenter – third approach using mocking framework
Previous examples were for the sake of clarity if we had to write our own mocks. Using third approach we define behaviour only of the method we test at a given time, we ignore rest of the methods from the interface as they are irrelevant in particular test. This is fast-to-write and clean solution to all our problems.