🐦 drongo

Mock Google Cloud Platform services in your tests - the moto for GCP.

Documentation

drongo lets you test code that talks to Google Cloud without touching the network, running an emulator, or paying for real resources. It stands up an in-memory, in-process fake of GCP service APIs and transparently intercepts the requests your google-cloud client libraries make.

If you've used moto for AWS, drongo will feel immediately familiar - that's on purpose.

Installation

pip install drongo

drongo does not depend on the google-cloud client libraries - you bring your own (google-cloud-storage, google-cloud-secret-manager, …). It mocks whatever you already use.

Quickstart

from drongo import mock_gcp


@mock_gcp
def test_upload_download():
    from google.cloud import storage

    client = storage.Client(project="my-project")
    bucket = client.create_bucket("my-bucket")

    bucket.blob("hello.txt").upload_from_string("hello drongo")

    assert bucket.blob("hello.txt").download_as_text() == "hello drongo"
    assert [b.name for b in client.list_blobs("my-bucket")] == ["hello.txt"]

No credentials, no network, no emulator. storage.Client() works with or without arguments - drongo supplies anonymous credentials and a default project while a mock scope is active. It also works as a called decorator, a context manager, a class decorator, or a unittest.TestCase mixin, and ships an auto-registered drongo pytest fixture - see the Quickstart guide.

Features

• 🎯 One decorator - @mock_gcp patches every supported service, just like @mock_aws.
• 🔌 Flexible - decorator, context manager, class decorator, or unittest.TestCase mixin.
• 🧠 In-memory & fast - no Docker, no emulators, no sockets; tests run in milliseconds.
• 🧬 Default clients, unchanged - drongo handles gRPC-first services behind the scenes.
• 🏃 Runs your code - opt-in executable handlers actually run your Python when a job runs, a task dispatches, or a message publishes.
• 🌐 Standalone server - drongo server speaks real HTTP so SDKs in any language can point at it.
• 🧪 pytest-native - a drongo fixture is auto-registered on install.
• 🧩 Extensible - adding a service is models.py + responses.py + urls.py, the same shape as moto.
• ✅ Typed - ships py.typed, checked with mypy.

Supported services

Full capability matrix: Supported services. You can also fill the mocks with realistic Faker data, or run drongo as a standalone HTTP server for non-Python SDKs.

How it works

drongo mirrors moto's architecture, adapted from AWS/botocore to GCP's REST+JSON APIs: HTTP services ship a models.py / responses.py / urls.py trio behind the responses interception layer, gRPC-first services run against an in-process emulator or a forced-REST transport, and state is sharded through a BackendDict keyed by project. See the Architecture tour for the full picture.

Roadmap

Available (8 services): Cloud Storage, Secret Manager, Pub/Sub, BigQuery, Cloud Tasks, Cloud Run Jobs, Resource Manager, Firestore - plus executable handlers, Faker seeding, and a standalone server.

Next up: Cloud Logging, Cloud KMS, IAM / Service Accounts, Cloud Scheduler, Cloud Functions, Datastore mode. See the full, tiered roadmap (services + capabilities, and how drongo compares to moto).

Want one sooner? Open an issue or contribute it.

Contributing

Contributions are very welcome! Adding a service is a great first PR. Start with CONTRIBUTING.md and the contributing-a-service guide.

git clone https://github.com/proxyroot/drongo
cd drongo
make install   # editable install + dev tools
make check     # ruff + mypy + pytest

License

Apache License 2.0 - the same license as moto.

Acknowledgements

drongo is heavily inspired by moto and owes its design to that project. It is not affiliated with or endorsed by Google or the moto maintainers.