Software Testing: Mocks and Stubs
In large projects such as the HappyFresh Fleet Tracker, classes and objects have varying dependencies in order to function. This has many repercussions, both positively and negatively. In this article, we’re going to discuss the matter from a TDD perspective in this matter, and how it affect how we create unit-tests.
De-coupling the Coupled
In unit testing, objects that we want to test may have varying dependencies on other complex objects. To isolate the behavior of the object, we may replace the dependency by mocking them, simulating the behavior of the real object.
These mock objects are used when there isn’t an easy way to verify that the intended code was executed, as it allows us to set up scenarios without invoking expensive resources like database and websocket receivers.
In our back-end stack, we use Golang’s mocking tool to generate a mock database as performed above.
Stubs
When testing objects that require parameters, stubs are used to simulate data or input without using preexisting real data. This ensures that every test on a particular object goes through the same process and has an expected output.
In the example above, we used a stub Admin object, containing dummy e-mail and password to test for authentication.
Mocks and Stubs are another aspect of TDD that I’ve discovered while developing our project. I hope that the knowledge I’ve gained here would be useful in the future!
