Weave Code
Soap Recorder Bundle Laravel Package
liip/soap-recorder-bundle
A Symfony bundle that records SOAP requests and responses and replays them in your test suite, letting integration tests run against realistic SOAP traffic without calling live services. Useful for stable, repeatable PHPUnit tests.
[DEPRECATED] Recorder/Player for SOAP communications
Frequently asked questions about Soap Recorder Bundle
- Can I use liip/soap-recorder-bundle in a Laravel application?
- No. The package ships a Symfony Bundle class, a DI extension, and XML/YAML service definitions, and Laravel's container consumes none of those. There is no Laravel service provider, no package auto-discovery, and no Laravel config surface, so the DI glue is unusable in a Laravel app. The underlying record-once/replay-thereafter pattern is relevant, but the packaging is not.
- How do I install liip/soap-recorder-bundle with Composer?
- The Composer name is liip/soap-recorder-bundle, but installation is only realistic for Symfony 2/3-era applications. On Laravel 10 or 11, Composer resolution will almost certainly fail on Symfony and PHP constraints, forcing --ignore-platform-reqs or a fork-and-patch. That is a permanent tax for a test-only utility, so do not install it just to obtain one recorder class.
- Is liip/soap-recorder-bundle maintained?
- No. The repository is archived and explicitly marked DEPRECATED, with about 12 stars and zero dependents. There is no security patching, no PHP 8.x or ext-soap fixes, and no handling for typed SOAP objects, fault responses, or WSDL drift. Treat it as a design reference, not a dependency.
- What does liip/soap-recorder-bundle actually do?
- It integrates SOAP recording and replay into Symfony applications by decorating the SoapClient transport boundary. It captures real SOAP requests and responses into fixture files, then replays them in later test runs by matching recorded calls to responses. The reusable idea is record-once/replay-thereafter with fixtures keyed by method and normalized arguments, plus explicit record, replay, and passthrough modes.
- What are the best alternatives to liip/soap-recorder-bundle for Laravel SOAP testing?
- Prefer HTTP-layer record/replay with php-vcr, or Laravel's Http::fake() if SOAP rides Guzzle over HTTP. If you need SOAP-level control, write a thin in-house SoapClient decorator behind an interface you own and bind it only in the test container. Use the deprecated bundle only as a reference implementation, not as an installed dependency.
- Does liip/soap-recorder-bundle support Laravel 10 or Laravel 11?
- No. Expect Symfony 2/3-era constraints and a PHP ceiling below current runtimes, so Laravel 10 and 11 are out of scope. Even with --ignore-platform-reqs, you would be vendoring an archived bundle to get one recorder class, which is worse than owning the class. Laravel version support is not provided and will not be added.
- How does liip/soap-recorder-bundle match SOAP calls to recorded fixtures?
- The design decorates SoapClient and keys a fixture by the request, typically method plus normalized arguments or a request hash. For deterministic replay you must strip timestamps, nonces, and message IDs from the request key, or replay will miss under load. If you build your own Laravel recorder, keep the same contract and make matching rules explicit.
- Is it safe to commit SOAP fixtures recorded by liip/soap-recorder-bundle?
- Be careful. SOAP headers routinely carry credentials, tokens, and PII, and the bundle's default behavior writes request/response pairs to fixture files that get committed. There is no built-in redaction control, so the team must own header and payload redaction and enforce it before fixtures enter version control. Secret capture is the headline risk in adopting this package.
- How much code is a Laravel SOAP recorder instead of using this bundle?
- Size it honestly at 200 to 400 lines of code plus fixture-directory conventions and a redaction step. Implement it in-repo behind an interface you own, with the recording client bound only in the test container and production bindings untouched. That is cheaper to own than a patched fork and legible to the whole team.
- What production and CI concerns come with SOAP record/replay testing?
- ext-soap becomes a hard CI dependency, so verify it in every build image, including Paratest workers. Fixture matching must be deterministic by stripping timestamps, nonces, and message IDs, and high-churn upstream WSDLs turn replay fixtures into false confidence. Keep production bindings untouched: the recording client should implement the same interface as the production client and be bound only in tests.
Weaver
How can I help you explore Laravel packages today?