Learn the Art of Faking with Mock and Stub ( Example in React )
One common scenario when creating a test is that components depend on another component that cannot be used at the production level environment. Let’s say you want to test your home page visuals but it calls the login component’s API fetching functionality, it is not recommended to do real API fetching — or another external module call like GoogleMap in React — when the purpose is to solely test. The reasons are as follows:
- Time-consuming: This can be very inefficient to be done repeatedly in many tests.
- Risky: This can harm the external parties like a database by accidentally modifying or removing data.
- Hard: Testing code will be harder and messier to maintain.
Today, we’ll learn the art of mimicking those external calls to make our test run more quickly and efficiently. This concept is also marching that testing a component should be specific for that component and we can fake the dependencies modules. It is called test double. According to Andrew Trenk, A test double is an object that can stand in for a real object in a test, similar to how a stunt double stands in for an actor in a movie.
Test double consists of some applications like Stub and mock that I will be explaining today.
Stub
You can use stubs when you need an object to return specific values. In the following example, the stub object is when the grades are set to 8,6,10. Thus, the test suite can focus on checking whether or not the average function works properly.
A grade service class has a constructor and a method to calculate the averages.
After mocking the Gradebook object, we stub its values—which are internally implemented inside the class — to a set of arbitrary numbers. Then, we call the averageGrades function by passing the stubbed student grades to check if the function returns the correct result.
Mock
Instead of defining the input manually, they usually call another function or pass in another action that can affect the program’s behavior that we want to test. Based on the developer’s assumption that doing A will affect B, a developer will call A first, then test if B matches his/her expectation.
We want to test a class named SecurityCentral that calls another module, Window and Door. Window and Door have a close() method, but we don’t want to test them yet. Rather, we focus on SecurityCentral’s functionalities.
The scope for the test is whether close() function is called when securityOn has been executed. To do that, we mock the Window and the Door object.
Common Use Case in React
Instead of calling real APIs in your test, we will mock this fetching function with fake data. This method can make the test run faster and avoid cases where the backend is not available.
To read more common use cases, please refer to React’s documentation: https://reactjs.org/docs/testing-recipes.html
How I Implement Mock and Stub in React
Since my project uses redux as a state management tool, I mock the redux’s store that stores isAutenticated value as false. Then, I render the JSX scripts and store them in getByText variable.
I mock three redux’s parts here: Sign up action, Authenticate action, and Redux’s store. Redux takes care of the state management logic and stores them. If you aren’t familiar with Redux, just think of them as other classes for this case. By mocking Auth and Signup actions, the logic behind the sign-up and verification process aren’t included, as they also include API calling.
getByText will store the JSX elements and we’ll check if “Buat Akun Baru” and “Operator” are displayed. The above codes might look complicated due to Redux, but you can just focus on lines 6 -12.
As said by some that Stub has no logic, I proofed them above. On lines 8–12, the code extracts form elements. As users type in, React’s useState function is called to perform state changes. The code tests whether useState function behaves appropriately. Thus, in the last paragraph, we just need to assert that the form values changed after the users have typed in.
Conclusion
Stub and mock are powerful tools to make code testing more efficient. As your application grows, inter-module interaction will occur more frequently. To avoid choking your tests, you can use them to create more specific/modular tests by mocking external implementations and save up your time. Happy coding!
