Module Amqp Laravel Package

Product Decisions This Supports

• Test strategy for asynchronous features. If your roadmap includes queue-backed work — order/fulfillment pipelines, email and notification dispatch, webhook fan-out, media processing — this module lets your acceptance suite assert on real broker state instead of trusting mocks. That directly informs how much confidence you can claim when you ship event-driven features.
• Build vs. buy for test tooling. The alternative is hand-rolling RabbitMQ helpers (php-amqplib + custom setup/teardown, queue purging, message grabbing) inside your test bootstrap. This package is a thin, MIT-licensed wrapper that already solves the boring parts: declaring exchanges/queues, pushing and grabbing messages, asserting queue existence and contents, and cleaning up between tests. Buying costs one Composer dependency; building costs ongoing maintenance of test infrastructure nobody wants to own.
• Roadmap gating and release risk. A concrete, repeatable way to verify routing keys, exchange bindings, and payload shape before deploy. That's the difference between "we think the consumer gets the message" and "CI proves it" — useful when deciding whether a messaging change is safe to ship behind a flag or needs a staged rollout.
• Use cases worth naming: asserting a job publishes to the correct exchange with the correct routing key; verifying the serialized payload contract a downstream consumer depends on; confirming a consumer drains a queue; asserting a queue stays empty on validation failure; isolating tests via per-test queue cleanup so suites stay deterministic.
• What it does not decide. It has no bearing on queue topology design, broker choice, or whether Laravel's queue abstraction is the right layer. It's a verification tool, not an architecture tool.

When to Consider This Package

Adopt when all of the following hold:

• Your team has standardized on Codeception for acceptance or functional suites. This is the single biggest filter — the module is useless to a Pest/PHPUnit-only shop.
• Your tests run against a real RabbitMQ broker (local, Docker, or CI service container), not an in-memory or fake transport. The module's value is broker-state assertions; if you're faking, it's dead weight.
• You need black-box assertions — "is this message actually on this queue?" — that unit-level mocks can't give you, typically at a service boundary or across a consumer you don't own.
• You want queue lifecycle handled for you (declare, purge, cleanup hooks) rather than writing that plumbing yourself.

Look elsewhere when:

• You're on stock Laravel/PHPUnit/Pest. Queue::fake() plus assertPushed/assertDispatched covers the majority of application-level queue tests with zero infrastructure, and it's what your team already knows. Reach for a real broker only when the abstraction itself is under test.
• You only need to test your own job classes in isolation. Mock the queue connection or use Queue::fake(); spinning up RabbitMQ for that is a tax on CI time and flakiness.
• You're on Symfony Messenger. Its test transport and inTransport() assertions are the idiomatic path and don't require Codeception.
• You need consumer-side contract guarantees across teams. That's consumer-driven contract testing (Pact or similar), not broker assertions.
• Support depth is a hard requirement. Be clear-eyed: 4 stars and 0 dependents means effectively no community, no Stack Overflow corpus, and no third-party tutorials. You are the support. It's under the Codeception organization and released recently (July 2025), so it isn't abandoned — but it is a long tail of one.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed test utility that lets us prove message-driven features actually work before they reach production — catching misrouted messages, wrong payloads, and broken consumer wiring in CI rather than in incident review. Cost is one dependency and a Docker service in the pipeline. The honest caveat: it's a low-adoption package (4 GitHub stars, no downstream dependents), so treat it as a thin convenience layer we could replace in a day if it ever stalls — not a platform commitment. Maintenance signals are acceptable: it's under the Codeception org with a release as recent as July 2025.

To engineering: It's a thin wrapper over php-amqplib that gives us readable acceptance-test actions — see a queue, push to a queue, grab a message, purge, assert contents — plus configurable cleanup so suites don't bleed state into each other. Real value is testing across a real broker at the boundary, which mocks don't cover. Two guards: pin the version and keep usage confined to a small set of test helpers so a swap is cheap, and gate adoption on us actually running RabbitMQ in CI — otherwise Queue::fake() is the better default and this is unnecessary complexity. Don't adopt it as a reason to move to Codeception; adopt it only if we're already there.