Generate mock data more easily with Faker library in your Sandbox

Nick Houghton, March 23 2015

Data generation helpers

This month’s platform update brings support for data generation helpers in the form of making the Faker library accessible to all Sandboxes. Generally when building stubs you want your stub data to represent the values created by the real system, but when it comes to addresses, names, emails, phone numbers etc it is easier to hard code one than generate a new realistic value everytime.

With this month’s platform update you can now use the Faker library to generate realistic data for many different properties increasing the value and accuracy of the Sandbox stubs you are creating.

There are quite a number of different properties available some of them include:

  • firstName
  • lastName
  • fullName
  • phoneNumber
  • email
  • city
  • streetName
  • streetAddress
  • streetSuffix
  • country
  • state
  • latitude
  • longitude
  • lots more!

Using the Faker library is simple, it is available to any of your JS code as a global variable already, no need to load or require() it in.

Sandbox.define('/test', 'get', function(req, res) {
    // send a random state as the response

The full list of available properties, including more details on functions and usages is available on the Faker page.

As well as data generation helpers, we’ve added CORS support to the Sandbox Runtime component available here, which should help everyone testing JS apps locally, and a bunch of bug fixes across the platform generally.

Try it out now, and hit us up with any feedback.

Automatic syncing of Sandbox definitions to Github

Nick Houghton, January 6 2015

This month’s platform update brings support for automatic two-way syncing your Sandbox definitions (main.js etc) with a Github repository of your choice and some API Blueprint importer bug fixes.

Two-way Github Syncing

Defining and having your stateful Sandbox stubs always running and testable in the cloud is great, but in a perfect world the stub definition should be in Git, versioned alongside your code and most importantly, your tests!

The new two-way syncing feature solves this problem for you. You can configure, at a Sandbox level, which remote repository and what subpath inside that repository you want the sync with. Once configured any change in the remote repository (under the chosen subpath), or change in the Sandbox platform will trigger the synchronisation.

The external repository syncing is available in the Sandbox Settings -> External Repository page. It requires that you grant OAuth permissions to your Github account, we use this to list your repositories, branches and to commit changes into your selected repository.

Importantly the syncing process only checks out the files and folders under the given subpath, /test/stubs for example. So none of your other code, configuration etc will be ever copied to our servers.

At the moment this syncing feature only supports Github, but Bitbucket support is planned soon.

Try it out now, and hit us up with any feedback.

Importing Apiary and Swagger

Andrew Stewart, October 20 2014

This month’s platform update brings support for generating mock services from Apiary and Swagger documentation, and an improved code editing experience.

Generate Sandboxes from Apiary and Swagger

If you’ve invested the time and effort to design your web API with the excellent tools available from Apiary or Swagger, you can now import your API design spec to generate a mock API implementation with Sandbox - getting your development teams up and running even quicker. Try it out now

We love designing APIs with Apiary however their mock server only provides simple canned responses. You can now add custom behaviour, dynamic responses and more when you import your Apiary API spec into Sandbox.

We’ve added support for Swagger too, with support for more formats coming soon. Hit us up with the format you’re after and we’ll prioritise it.

Improved code editing experience

You’ve probably noticed that the dashboard and coding experience have undergone an overhaul. Everything you need to code, inspect and debug your sandboxes and API integration problems is now available on a single page.

Sandboxes now support splitting your code into multiple modules. If you’re familiar with NodeJS require to import modules then you’ll know how to work with Sandbox imports right away. See the docs for more details.

Forking Sandboxes

Creating sandbox clones is a great way to ensure tests can run in parallel with completely isolated independent data and now you can tweak the behaviour of a sandbox without affecting other clones. Forking a sandbox provides you with your own copy complete with a Git repository to push changes too. Note that your forked sandbox will no longer receive updates from the original. Any sandbox you have access too can be forked from a sandbox’s project page.

We always welcome feedback from our users, reach us at twitter.

Options for testing your iOS and Android apps, APIs and backends with stubs.

Nick Houghton, September 21 2014

A problem

Building an API or web-services backed mobile app poses some unique problems that don’t really come up together in other applications. There are a couple of things that make them unique:

  • Need an API call to retrieve any resource not shipped in the app itself
  • Better user experience if the app bundle is small (faster updates etc.)
  • Generally pushing a new app bundle is a multi day/week journey (Apple approvals etc.)
  • Its mobile, which means by definition you are testing on a number of different devices, in different places.

What this means in terms of testing your API backed app is that you might encounter three types of issues:

  • You want to build out your UI, wire everything together and start validating the design and flow. But your API doesn’t exist yet!
  • Your API is being built, but isn’t publically accessible for your wider set of testers. Can’t test everything sitting at your desk, on Wi-Fi, hitting your local server.
  • The API is built and deployed! But to test edge cases and rainy day scenarios the testers need more control over how the API behaves to cause errors.


There are a few different approaches and options to solve these problems; they all focus around simulating or stubbing out the real backend API at some level. Nothing beats the real API, but that isn’t always practical, the closer we get to the real API the more valuable (but potentially costly) our testing will be.


A fixture is a codified stand-in of a particular object in your application; it is generally used for unit tests where the desire is to test one particular unit in isolation. It is obviously possible to use a fixture to simulate backend API calls, but it can cause problems with later testing.

One of the most important aspects of integration testing, is testing the integration between the app and your backend and to do that properly the request should go over the network. This step is obviously missed when using fixtures, as they are part of the app itself.

The reason this is important is a large portion of these integration problems occur in the serialization/deserialization and protocol conversions (think Content-Types, Cookies, JSON types, XML!! etc.) and these only take place if you actually make a request!

Write a stub

A stub or mock is a small often throw-away application that aims to simulate as much of the target API as required. The simplest and most common implementation of this is a stub that responds to requests with a different ‘canned’ response, so you get a valid API response but it is the same response every time you make the request. These can obviously get more and more complicated as time goes by, with more and more varied canned responses to simulate different behaviours.

There are many different libraries out there to make the job of writing a mock easier, they all generally focus around making it very easy to send a canned response to a given request. But this is only half of the problem, many API operations are not just Retrieves, what about Create, Update and Delete? It is generally very difficult to get a stub to do more than just retrieves well, making testing your app against the stub a limited and unnatural experience.


A relatively recent addition to the landscape, a MBaaS (Mobile Backend as a Service) aims to take away the pain of building a backend entirely, so you can just worry about building the app. Parse and Firebase (sort of) are examples of these.

In the MBaaS approach, because you build the app against their backend from Day 1, you always have a backend available to develop and test against avoiding many of the problems discussed earlier.

However this introduces new problems, the biggest worries for me are around vendor lock-in, lack of a real API and describing business logic.

The lock-in occurs because each of the MBaaS providers do it differently and once you have spent the significant amount of time integrating and making everything work, changing can be a rewrite.

Similarly the API exposed by the provider to manipulate your data is generic, not purpose built for your app or your data. This means instead of your API being a reusable asset, it becomes unsuitable for consumption outside your app.

Finally describing your business logic, a tough enough job as it stands already, is made more difficult by the added abstraction and constraints of the MBaaS service. Each of them support business logic in a different way but obviously none are as simple, maintainable and portable as building it yourself.


We conceived Sandbox to solve these problems, so it is not surprising that we think it does the best job.

Sandbox is a cloud hosted stubbing platform that allows you (and your collaborators) to create stubs ranging from simple canned responses, to complex fully simulated applications, all in a simple Git versioned JavaScript environment.

As well as the simple Sandbox runtime (open source on github), we built a set of tools on top of this to make developers and testers jobs easier (more details). To support the often tricky jobs like debugging requests, modifying responses and applying non-functional behaviour like response delays.

In Sandbox you are creating routes to simulate your real API. You start by either mocking out your API manually or preferably import your API definition. We support definitions such as Apiary markdown, WSDLs or Swagger to shortcut the process.

Most Sandbox implementations start out with simple canned responses, but can be easily extended to support logic and stateful behaviour. Each Sandbox has access to its own zero-effort persistent storage. This means simulating proper CRUD APIs is really simple, check out the api

Sandbox solves the challenges of API integration by giving teams an unlimited number of always-on and accessible drop-in replacement environments, a simple scripting runtime and powerful debugging tools. Whether you have an existing API your testers want more control over (failure scenarios are important!), or you are still designing your API and want to import your design and test the UI flow before proceeding, that’s why we built it!

Try it out for free!

Reducing Gradle memory usage during JavaExec.

Nick Houghton, August 26 2014


We develop Sandbox in a Vagrant virtualbox environment, this affords us many benefits like simple setup, faster developer onboarding etc, but running all the components of your application inside a virtual machine means it is going to have to live with less resources than if you were running it natively (generally).

We recently started having slow downs and OutOfMemory exception errors during development and after a bit of investigation the root cause ended up being Gradle. We use Gradle for dependency management, some build tasks and most importantly we use it to start the JVM during development time using the JavaExec task.

The JavaExec task is a really convenient way of running your app with all its dependencies from the command line, in the same vein as a mvn run/jettyRun. The problem is that when Gradle runs a JavaExec task, it starts a Gradle JVM to resolve and compile the dependency graph and then forks a new child process to start your application, leaving the parent Gradle process running. In our case this parent Gradle process was taking up 200MB RAM, and depending on how many of the application components were running, there could be up to 4 Gradle processes running totaling 800MB of RAM wasted. Our Vagrant VM only had 1500MB allocated, no wonder we were getting OOMs!

The solution

We needed a solution where Gradle still maintained the dependency graph, but delegating the actual running of the JVM to the OS and not fork a child process itself. This is an inherent problem with Java, as the underlying Java mechanism of running processes Runtime.exec(...) doesn’t support detached child processes.. anyway.

So to get around this we want Gradle to write out all the JARs (with absolute paths) that the application requires to run to a file, then get the OS to execute Java with that classpath. Here is quick and dirty version:

task createdeps() {
    def file = new File("/tmp/")
    file.write("/usr/bin/java -cp " + sourceSets.main.runtimeClasspath.asPath + " com.test.YourMainClass");

We create a new task called ‘createdeps’ that will write a script to the /tmp/ directory that can be executed to start a new JVM for our application. The script contains the full classpath as seen by Gradle, you should only have to replace the last parameter with your fully qualified Main class and it should work OTB! Because this Gradle task doesn’t actually run anything, it just introspects the classpath, gradle should exit as soon as it has written the script, unlike a JavaExec task.

Tying it all together, a one-liner to write out the script and execute it:

gradle createdeps; sh -c /tmp/

800MB RAM Saved!

Newer    Older