Engine Integration Tests Laravel Package

Product Decisions This Supports

• Build vs. buy decision for SOAP interoperability: This package supplies the conformance suite that implementations of the php-soap engine contract run against. Use it as the objective “definition of done” when deciding whether to keep ext-soap or adopt php-soap/engine (pure PHP) in a Laravel service.
• Roadmap / upgrade risk: A green run against these tests is evidence that a SOAP engine swap (or a PHP minor-version bump) won’t silently break payload encoding, WSDL parsing, or fault handling — a concrete input to planning the migration ticket.
• Vendor and platform portability: Supports the “run SOAP without the native extension” story — relevant where ext-soap is unavailable, pinned, or behaves inconsistently across base images and PHP versions.
• Procurement / dependency confidence: A maintained, independently versioned integration-test suite signals that the upstream php-soap ecosystem is actively validated, which strengthens the case for depending on it in production paths.
• Release 1.12.0 specifically: A single internal test correction (Dom\Element nodeValue in AbstractEncoderTest) — a test-suite accuracy fix, most relevant to PHP 8.4 DOM API behavior. No public API change, no deprecation, no breaking change. Safe to bump; no product decision is altered by this release, it only slightly improves the reliability of the conformance signal.

When to Consider This Package

Adopt it when:

• You are maintaining or evaluating a SOAP engine implementation (including php-soap/engine) and need a portable, engine-agnostic correctness suite rather than hand-rolled fixtures.
• You are migrating off ext-soap or running SOAP code in environments where the extension isn’t available, and want a repeatable before/after comparison as a CI gate.
• Your team needs cross-PHP-version confidence for XML/DOM-sensitive encoding behavior (this release is precisely that class of fix).
• You want the SOAP layer treated as a testable component rather than an opaque vendor black box.

Look elsewhere when:

• You are simply consuming a third-party SOAP API from a Laravel app. This is not a client, mocking, or HTTP-faking library — reach for Laravel’s Http::fake(), WSDL stubs, or recorded fixtures instead.
• You expect to write application-level feature tests; this package tests engines, not your business logic.
• You are not prepared to run it as a dev-only dependency in CI; it adds no runtime value and shouldn’t ship to production.
• You need support SLAs or long-term vendor guarantees — this is a community-maintained test harness, not a commercial product.

How to Pitch It (Stakeholders)

For executives: We’re evaluating a low-cost, dev-only test suite that tells us — mechanically, not anecdotally — whether our SOAP integrations behave correctly across PHP versions and across SOAP engine implementations. It converts a risky “swap the SOAP engine and hope” migration into a CI-verified checklist. Cost is negligible; the value is de-risking a migration and avoiding an outage in a revenue-adjacent integration path.

For engineering leadership: It’s the shared conformance suite for the php-soap engine contract. We add it as a require-dev dependency, wire it into the pipeline, and get an objective pass/fail on encoding, decoding, and WSDL behavior instead of maintaining our own parity fixtures. The 1.12.0 release is a maintenance fix to the suite’s own encoder test — no API surface change, no action required beyond a routine version bump. Recommended next step: a one-sprint spike to run the suite against our current stack and record a baseline before any engine change.