# Fake sandbox
Fake sandbox is an approach of creating a Sandbox environment that fakes all of your application external dependencies. The fake external dependencies you create are usually not suitable for production use as they are designed lightweight to be used on a local machine.
This approach comes with the risk of “but it works on my machine” — where the fake external dependency might behave differently when it’s put in production. It’s a good practice to test your application on a production-like environment, therefore if your production is using MySQL for example, you should use MySQL in your sandbox.
# References
Mocks Aren’t Stubs (opens new window)
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database (opens new window) is a good example).
# Backlinks
- How might we create a sandbox for a cloud application?
- Fake sandbox: Create fake cloud services locally
- Prefer cloud sandbox for serverless architecture
- Fake sandbox and Cloud sandbox comes with their own advantages and disadvantages (How might we create a sandbox for a cloud application?). It is difficult to choose an option when there’s no context is given. Given a context that you are building serverless architecture, you should default to the cloud sandbox approach. All of the downsides of cloud sandbox are invalid when you’re building serverless architecture.
- Test application and infrastructure as a whole
- Even though you can achieve a similar test coverage with Fake sandbox, there is a risk of “but it works on my machine” — where integration doesn’t work in the cloud. It’s difficult to fake the cloud services well because Can we fake a cloud platform?. This late integration issue introduces a slow feedback cycle as you’ll only discover problems further in your deployment pipeline.