Imagine you’re directing a movie. You have an action scene to film ahead and the actress who is really good at acting has a bad knee or acrophobia. Now, she isn’t able to jump off that tall building and land safely on the other building, but you have somebody who is fully prepared to take that shot: the stunt double.
The same could be applied to software development. We are constantly integrating applications with other applications and many times while filming, we find out that the target application has a bad knee or doesn’t have one at all. That said, it’s important to keep in mind we also have at our disposal something that is fully prepared to help us getting that shot done: the Test Double.
Chapter 1: the Test Double
When developing software, very often we need to test the SUT (system under test) against components that cannot be present in our test environment. Test Double is a generic term used to describe the replacement of the real DOC (depended-on component) for a similar version provided by us. Something important to be aware of is that it isn’t necessary to implement the whole DOC, but only provide the functionality that is needed for the particular test we are executing.
Test Doubles have different flavors and can be applied depending on how/why we want to use them. The flavors are: Dummy Object, Test Stub, Test Spy, Mock Object and Fake Object. For the purpose of this post, the chosen flavor will be the Fake Object. This specific flavor can be used whenever we need a lightweight implementation of components that are unavailable, make tests difficult or slow. For instance, you can apply it to database, in-memory database or web services replacements.
Chapter 2: the GetSandbox
GetSandbox is a tool that allows us to mock RESTful APIs and SOAP web services in a very straightforward way including the ability to generate them from API definitions like Swagger, WSDL or RAML. When it comes to web services, GetSandbox fits perfectly as the Test Double previous mentioned and can be placed in our test environment as follows:
The blue parts are the parts we could replace as Test Doubles using GetSandbox. Something interesting about this tool is the ability to choose between running it in the cloud or within your own infrastructure. For the cloud service, you can subscribe to a plan that fits your test needs better without the hassle to manage everything yourself. The second option is suitable for when you’re working on a product where accessing any service in the cloud is not allowed. GetSandbox is an open source project and you can download it here.
Well, as we saw in the previous chapters, GetSandbox is a perfect fit when we need a Test Double. By experience, I can say that GetSandbox is a very handy tool for us to use as developers in our daily activities. It’s very common to find components that are unreliable, lack performance or don’t provide means for us to make our application robust and more resilient.