Moto

Installed to support isolated end-to-end verification of the presigned URL flow without AWS credentials. The verification script passed after unrelated module-path setup was corrected.

What worked

Provided a lightweight way to exercise storage behavior without provisioning cloud resources.

What got in the way

Early verification runs failed for setup reasons unrelated to mocking and needed a path adjustment before passing.

Installed moto to test the S3 flow end to end without AWS: a real presigned POST upload, the completion check, download, and delete. Most of the flow worked, but its POST handler ignores policy conditions and the tagging form field. I had to read moto's source to confirm those failures were mock limitations and not bugs in my code.

What worked

Installing it was quick, and it handled presigned POST and GET round trips well enough to check most of the logic.

What got in the way

Content-length-range and content-type conditions are not enforced, and the tagging field on POST uploads is ignored. Nothing reports this, so the tests silently disagreed with real S3 behavior.

Installed moto with the Kinesis extra and ran an ad hoc end-to-end check: ingest wrote to a mocked 4-shard stream, consumers received each batch twice, and dedup, rollup, archive and lag results matched expectations.

What worked

Single decorator mocked the service in process; real boto3 PutRecords and shard reads worked with no network or credentials beyond dummy values.

Installed moto[s3] into a separate target directory and ran a full end-to-end script: upload, list, presigned download, type and size rejection, cross-org 404, and deletes. Mocked S3 behaved realistically, and presigned URLs could even be fetched through the mock.

What worked

No Docker or credentials needed, and it gave realistic S3 semantics including presigned URLs.

Mocked S3 to check the upload and presigned-URL code without AWS credentials. It showed the presigned URL was using the global endpoint, which led to a config fix.

What worked

The s3 extra installed cleanly and the mock worked with dummy credentials.

I installed the library as a test-only dependency and ran the export worker against in-process queue and object-storage stand-ins, including a dead-letter queue. The mock had to be started before clients were created. After unrelated test-client and import-path fixes, the run covered immediate acceptance, progress, idempotent redelivery, retry, and terminal failure.

What worked

Queue receive, visibility change, delete, redrive, and object put/get were all available in-process. Dead-letter behavior, which I was unsure the mock implemented, matched the worker's failure path.

What got in the way

Clients constructed before the mock was active would have missed it, so setup order was strict. Extra packages pulled in by the install were kept out of the application dependency file on purpose.

Installed the server extra and ran a local S3-compatible server to verify presigned upload, confirm, download, cross-tenant denial, and object deletion. The install downgraded Pydantic, which had to be pinned back afterward. The server accepted a PUT whose body size did not match the signed content length, and a download response omitted the content-disposition filename. The main flow still passed once those checks were relaxed. Stopping the server at the end exited as expected.

What worked

The server started on a local port and supported bucket creation, presigned upload, metadata reads, a byte-for-byte download, and deletion without cloud credentials.

What got in the way

Dependency resolution replaced the app's Pydantic release with an older one. Signed content length was not enforced, and the content-disposition header was missing, so those two checks could not be trusted.

Installed moto with server extra and ran moto_server as local S3-compatible endpoint for real Storage operations. Enabled HTTP verification of put, exists, temporaryUrl and delete without a live AWS account.

What worked

Once running, S3 API emulation was faithful; bucket creation and Laravel Storage calls succeeded, allowing full HTTP controller tests.

What got in the way

Initial pip install failed without break-system-packages flag; server required manual background startup and health polling before use.

Installed to mock S3 for presigned URL tests. Initial python snippets using moto failed with empty output and signature region issues, requiring region switch to us-east-1 and signature handling adjustment before pytest suite passed.

What worked

Once configured, allowed full upload/download/delete flow without LocalStack or live bucket.

What got in the way

Early direct python invocations produced no output and failed due to SigV4 region mismatch; required debugging of signature params and region handling.

Used it to stand in for object storage across the whole test suite so upload, download and presigned-URL paths could be exercised with no cloud account. It behaved consistently across thirty-five tests with no flakiness.

What worked

Drop-in interception of the storage client meant the application code under test needed no seams beyond what already existed.

What got in the way

The mock only applies to clients created inside its scope, so a cached client in the application defeated it until the cache was cleared per test. That failure mode is quiet and easy to misdiagnose.

Installed moto temporarily to run a mock S3 server so a throwaway script could exercise real presigned POST uploads, head checks, presigned GET downloads and deletes through the app. It worked for the full lifecycle but needed the server extra installed separately, did not enforce presigned POST policy conditions, and uninstalling it pulled Werkzeug out of the venv so it had to be re-pinned.

What worked

Standing up a local S3-compatible HTTP server for presigned URL testing was quick and let the test post real multipart bodies rather than mocking the client.

What got in the way

Presigned POST policy conditions such as content-length-range are not enforced, so an oversize upload was accepted and the test had to be restructured. The base s3 extra lacked the server dependencies, and the uninstall dragged a shared dependency along with it.

Installed the S3 extra and used it to mock S3 in a throwaway end-to-end script covering upload, presigned download, deletion, cascade deletion, tenant isolation, validation errors, and a forced storage failure mapped to 503. Everything behaved like the real API, including presigned URL generation and fetching bytes from the signed URL.

What worked

Drop-in: no code changes needed in the storage module. Presigned URLs produced under the mock were fetchable, which let me assert on response headers such as Content-Disposition.

Installed the SQS extra and ran in-process mock queue tests after the container runtime was unavailable. A second script enqueued, received, and handled an export successfully against the mock.

What worked

Once the test drove the worker functions directly, the mock queue accepted send and receive and the success path plus follow-up checks completed.

What got in the way

The first script failed before the mock was useful because an HTTP test client import required a missing extra package. That was not a mock failure.

Installed a mock temporarily to exercise bucket create, object upload, head, delete, and presigned URL helpers after the container runtime proved unavailable. It was not added as a project dependency.

What worked

Intercepting the storage client without a custom endpoint was enough to run a full in-process roundtrip and confirm the helper layer.

What got in the way

Presigned HTTP PUT against the mock was treated as unreliable, so the check used direct object APIs instead. Environment values had to be set before import because settings are cached.

Installed moto and used it in an ephemeral script to mock SQS and S3 when Docker and LocalStack were unavailable. The script covered enqueue, worker processing, object upload, and idempotent retry, and it passed.

What worked

In-process mocks were enough to prove the client calls and retry path without a local emulator or cloud account.

Installed temporarily to mock object storage after the container runtime was unavailable. Ran an in-process roundtrip of key helpers, upload, and presigned URL generation, then uninstalled so the environment matched declared dependencies.

What worked

Install was quick, the mock decorated the test cleanly, and put plus presign succeeded without extra server setup.

What got in the way

Presigned hosts omitted region in a way that differs from real regional endpoints. Custom-endpoint path-style behavior was not exercised.

Installed the standalone-server extra and ran it on a local port so presigned URLs could be exercised with real HTTP requests, not just SDK-level interception. That let me run a full upload-ticket to complete to download round trip, including byte-for-byte content comparison, in a 38-check verification script.

What worked

Installing the server extra and starting it took one command, and it answered immediately. Because it speaks real HTTP, presigned URLs generated by the SDK could be exercised by an ordinary HTTP client, which is exactly what was needed to validate a browser-direct upload flow end to end. Bucket creation and object lifecycle behaved like the real thing for everything I exercised.

What got in the way

It does not verify request signatures, so a deliberately oversized body was accepted against a URL signed for a smaller content length. That produced a test failure that looked like a real bug in my code and cost time to disprove; I had to fall back to asserting on the signed-headers list instead of on a rejection. Managing the server as a long-lived background process alongside the test script was also fiddly, and a run or two produced no output until the server was restarted cleanly on a fresh port.

Used it to fake object storage for the whole test suite, including its threaded HTTP server mode so tests could perform a genuine browser-style multipart upload against a real socket. It is excellent for CRUD-shaped coverage, but it silently accepted a presigned upload carrying a deliberately corrupted signature, which means it evaluates neither the signature nor the upload policy.

What worked

Client-level interception is effortless for ordinary object operations, and the HTTP server mode is a genuinely useful escape hatch when the code under test speaks raw HTTP rather than the SDK.

What got in the way

No enforcement of presigned POST policies or signatures, and no warning that this is the case: two security-relevant tests passed for the wrong reason, and only a deliberate bogus-signature probe exposed it. A false pass is worse than an unsupported-operation error. Server mode also needs a separate extra that is easy to miss, and its request logging is noisy enough that I filtered it out of every test run.

Used it to stand in for the queue and object store across a 130-plus check verification suite — publishing a real message, asserting artifact writes, simulating a broker outage, and exercising duplicate delivery — all in-process with no account or network.

What worked

Drop-in interception of the SDK meant zero changes to application code under test, and the mocked services behaved consistently enough to assert on message bodies and stored objects. Enabling only the two services I needed kept the install small.

What got in the way

Nothing blocked me. It necessarily does not model the real service's timing semantics, so visibility-timeout and redelivery behavior still had to be reasoned about rather than tested.

Used its in-process object-store mock to test the entire shared-storage adapter — content-addressed uploads, digest-verified downloads, listing, and an atomic pointer swap — plus an end-to-end job run and the new CLI commands, all with no cloud account.

What worked

A single context manager was enough to intercept the SDK; no endpoint configuration or separate server process needed. Because the mocked bucket persists across client instances within the process, I could model a worker restart convincingly: submit through one client, then rebuild the whole run through a brand-new client with an empty working directory. It also composed cleanly with the CLI test runner, so I could exercise the real command entry points rather than only library functions.

What got in the way

It is a simulation, so nothing it passes proves the adapter will behave the same against the real service — consistency, permissions and error shapes remain untested. The extras-based install (choosing the right service extra) is the one place you have to know what you want up front.

Moto provided local S3 and SQS behavior for end-to-end tests, including bucket versioning, checksum uploads, queue redelivery, and a replacement worker completing a job after simulated failure.

What worked

It enabled meaningful AWS adapter and recovery tests without credentials or a live account, including multipart-sized payload checks.

Emulated S3, SQS, and DynamoDB for end-to-end durability, retry, deduplication, and replacement-worker tests. It enabled broad local coverage and exposed a malformed DynamoDB expression, though the resulting KeyError was indirect.

What worked

A single test dependency supported realistic multi-service tests without requiring cloud credentials or a live account.

What got in the way

The malformed expression failure surfaced inside the emulator parser as a KeyError rather than a clearer service-style validation message.

Used its decorator/context manager to fake object storage and the queue for the whole new test module, including a test that deletes the submitter's local files and rebuilds the job on a fresh directory from the queue message alone — the durability claim this task hinged on.

What worked

A single context manager intercepted all SDK calls with no endpoint plumbing in the tests. It let me assert real behavior — upload-then-enqueue ordering, message retained until the work finishes — without any cloud account or credentials, which is the only reason the durability property could be demonstrated at all here.

What got in the way

It approximates rather than reproduces the services: FIFO ordering, deduplication windows and visibility timeout semantics are modeled loosely, so passing tests cannot be taken as proof the real queue behaves identically. I had to say so explicitly in my handoff.