Fake It ’Til Your Tests Pass
The classes, objects and functions in our code have various dependencies to make them work. For example, our frontend code needs to fetch data from the API. However, during testing, we shouldn’t make actual calls to the API. Other than that, it would be hard to spot bugs if we test all components of our code altogether. We need to break down our tests into smaller systems. This leads to the topic of test isolation where we will be using test doubles.
Based on this Google Testing on The Toilet article, an analogy for test doubles is a stuntman who replaces an actor in a movie. Similarly, test double stands for a real object in a test. The test doubles that I’m going to discuss in this article are stubs and mocks.
Stubs
We use stubs when we want to call data. But instead of using a real database or creating real HTTP requests, we can stub it instead. Stubs are used when we need our object to return a specific behavior so our code will be in a certain state. Stubs use no logic and only return the predefined data.
In Flutter, we can use the Mockito package to help us stub and mock data. Here’s an example of stubbing HTTP request in Flutter from our mobile app code:
On the first test ‘Test program progress with image’, it is expected that a camera icon will be displayed on the UI if the image exists. On the second test, a camera icon shouldn’t be displayed if the value of camera key is null. To know if the image exists or not, we must obtain the data first, but instead of fetching actual data from the API, we stubbed the HTTP request to return a specific value.
Mocking
Mocks are used to test interaction between objects. We use mocks to verify whether a certain object is called. It is useful when it’s hard to detect state changes and there is no return value. Below are some example codes from our mobile app repository.
First, let there be a BLoC class called GoodsDonationBloc:
Then, we have another BLoC class called ChangeBottomNavigationBarBloc:
Curious about how to mock this? Here’s the test:
Our GoodsDonationBloc depends on the ChangeBottomNavigationBarBloc because when our user successfully donates something, GoodsDonationBloc will notify ChangeBottomNavigationBloc that a donation has occurred. To test this, we stub the HTTP request first which returns a 204 status code which means that the request succeeded. If the request succeeds, we have to yield the SendingGoodsDonationSuccess() state, where leads to the DonationOccur event in our ChangeBottomNavigationBarBloc. To check if the event occurred or not, we mock it using the help of the verify() function (see line 18).
Stubbing and mocking have helped me and my team a lot in creating our test for our project. Mocking and stubbing isolate our tests from external dependencies. Aside from helping our test runs faster, it also makes it more reliable. If there’s failing tests, we know that the bug occurred on our code under test instead of the dependencies.
References:
https://www.codemag.com/Article/0906061/Isolating-Dependencies-in-Tests-Using-Mocks-and-Stubs
https://testing.googleblog.com/2013/07/testing-on-toilet-know-your-test-doubles.html
https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da
https://circleci.com/blog/choosing-the-right-technology-stack-for-your-startup/
