Skip to content

test(openapi): assert the yaml export structurally, not by key order - #8464

Merged
soyuka merged 1 commit into
api-platform:4.3from
soyuka:fix/openapi-yaml-symfony-dev
Aug 16, 2026
Merged

test(openapi): assert the yaml export structurally, not by key order#8464
soyuka merged 1 commit into
api-platform:4.3from
soyuka:fix/openapi-yaml-symfony-dev

Conversation

@soyuka

@soyuka soyuka commented Aug 16, 2026

Copy link
Copy Markdown
Member

Fixes the last blocking failure on 4.3: OpenApiCommandTest::testExecuteWithYaml on the PHPUnit (PHP 8.5) (Symfony dev) job.

Cause

The test matched rendered YAML blocks that assume operationId comes directly after get::

  /dummy_cars:
    get:
      operationId: api_dummy_cars_get_collection
      tags:
        - DummyCar

Under symfony/serializer 8.2.x-dev the Operation properties are emitted in a different order — responses first:

  /dummy_cars:
    get:
      responses:
        '200':

Nothing is missing. operationId and tags are still there with the same values, just later in the mapping. I verified every individual fragment the test expects is present in the dev output; only the multi-key blocks fail. Object key order is not meaningful in YAML, so this is a test that over-specifies rather than a bug in the export.

Note the failure was not YAML formatting drift, which is what the symptom initially suggested.

Fix

Assert the parsed structure for the paths, and keep separate string assertions for the formatting this test genuinely covers — block sequences and inline empty arrays:

$parsed = Yaml::parse($result);

$this->assertSame('api_dummy_cars_get_collection', $parsed['paths']['/dummy_cars']['get']['operationId']);
$this->assertSame(['DummyCar'], $parsed['paths']['/dummy_cars']['get']['tags']);
$this->assertSame('api_dummy_cars_id_get', $parsed['paths']['/dummy_cars/{id}']['get']['operationId']);
$this->assertSame([], $parsed['paths']['/dummy_cars/{id}']['get']['tags']);

The remaining assertions — literal-style multiline description, quoted title, the nested security block — are unchanged; they were already order-independent and still pass.

Verification

Reproduced locally with CI's recipe (composer config minimum-stability dev), which installs symfony/yaml, symfony/serializer and symfony/framework-bundle at 8.2.x-dev. The full file then passes:

symfony result
8.2.x-dev OK — 6 tests, 36 assertions
8.1 stable OK — 6 tests, 36 assertions

(The 6 risky notices about exception handlers are pre-existing and appear on both.)

testExecuteWithYaml matched rendered YAML blocks that assumed operationId came
directly after get:. symfony/serializer 8.2.x-dev emits the Operation properties
in a different order -- responses first -- so the blocks no longer matched even
though every key is present with the same value.

Object key order carries no meaning in YAML, so assert the parsed structure for
the paths and keep separate string assertions for the formatting this test is
actually about: block sequences and inline empty arrays.

Verified on symfony/yaml 8.1.2 and 8.2.x-dev.
@soyuka
soyuka merged commit 36d457f into api-platform:4.3 Aug 16, 2026
110 of 112 checks passed
@soyuka
soyuka deleted the fix/openapi-yaml-symfony-dev branch August 16, 2026 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant