As a long time developer of many different projects, ranging from simple websites that I have developed solely, to multi-service behemoths that had multiple teams in multiple time zones, I have faced many problems when trying to stay agile, and not block other teams while doing my job.
Mocks, fakes and stubs
Most of the readers are probably familiar with what these are, but for those who aren’t, they represent different levels of abstractions that simulate or clone the behavior of real “things”, such as objects or functions. They are different in some ways; fakes, for example, can be minimal implementations of actual objects, but a real implementation nonetheless. Mocks and stubs usually don’t have any underlying implementation. These are generally used when writing tests, and one of the biggest issues with them is external API calls, cross service calls or invoking external services. And probably biggest of these is external services. There are solutions that you can code, but when you actually want to mock something outside of the test environment, or during development, it becomes really hard.
Real life example
Imagine working on a piece of code that communicates with a different service or a device that is performing an action to which the device can respond in multiple ways depending on certain parameters. The team working on the firmware for the device know what the device is supposed to respond, you know what your service is going to send. Most of the time you can just code in the lack of actual communication and just rewrite the method once their implementation is complete. But why do that, why go through all of the trouble of creating code that will be modified when you can mock the device endpoint, and make your work easier.
Benefits of using mocking for this scenario
With mocking, you get a chance to establish a contract that both you and the firmware team can follow. You can do that with a simple text file, but it gets cumbersome sharing it and managing updates and you still need to code the lack of an actual server. You can do it with downloadable mock servers, but then you have to manage them and you still haven’t solved the lack of updates between teams. That’s where mocking services like Mockadillo come in. By thinking ahead, and having a single place where you can see what is expected of both teams to provide for successful inter-service communication you improve the quality of workflow, as it’s can be clear what the scope and scale of your work is. Another benefit is, you are decoupled from the other team. While they are busy developing their functionality you can develop your part of the application without worrying about their availability, their changes, and possible errors. Services like Mockadillo are highly available, you can view the communication contract whenever you want, you are notified of updates and you can simulate different scenarios based on what you need, whether it’s error simulation, creating a delay, a timeout, or just invoking different responses depending on the request.
Better development process
Probably the first thing I and my colleagues abstract away is talking with other services, or for web/mobile apps API communication. You can probably get away with having a simple function/class that holds the host, and has different methods for different calls that you want to make. Well, imagine accepting a parameter that represents the host value, which can have a value that is the mock server during development, and then just swapping it out when the target functionality is ready. That way you never have to modify your code and you can always work as if the target functionality was always there. And it goes both ways, when you start working on something that another team is highly dependent on you can lose the pressure of colleagues or that annoying PM bothering you to hurry up. So for your next project consider mocking your API with us, it might just save you some headaches in the process.