Tutorials & Integration Guides
Three tips for testing Fog with RSpec
Fog is a solid Ruby library for working with cloud services, but its documentation gets thin fast when it comes to testing. While building QuotaGuard, I ended up relying on Fog’s built-in mock mode and a few RSpec habits to keep the test suite sane. The first habit was treating Fog’s mock state like a database. In every spec, I enabled mocking and reset Fog’s in-memory model before each example. If I did not, tests would silently leak state into each other and failures would show up far away from the cause. The second habit was accepting that Fog mock mode starts as a blank cloud. It does not know anything about my real AWS setup. No buckets, no keypairs, no load balancers, no instance IDs. That means any dependency my production code assumes exists has to be created in the mock environment first. A simple example is creating an EC2 instance with a :key_name. Fog validates that the keypair exists. In production it already does, but in mock mode I had to import that keypair before calling the code under test. The third habit was being intentional about Fog’s simulated delay. Fog can mimic the real-world lag between “resource created” and “resource ready,” which is useful when testing code that waits or polls. But across a large test suite it can be unnecessary drag. When I wanted speed and determinism, I set Fog::Mock.delay = 0. When I wanted to exercise readiness assumptions, I left the default delay in place. The basic pattern was consistent: reset mock state, build only the cloud resources the test needs, then choose whether I care about readiness timing for that specific test.
.webp)
