- Can I use lchrusciel/api-test-case in a Laravel application?
- No. It is a Symfony-only package: it extends Symfony\Bundle\FrameworkBundle\Test\WebTestCase and drives assertions through Symfony's KernelBrowser, which is a completely separate lineage from Laravel's Illuminate\Foundation\Testing\TestCase and MakesHttpRequests helpers. There is no Laravel adapter, and booting a Symfony kernel inside a Laravel test suite is not viable. What does transfer is the pattern, not the package: coduo/php-matcher is framework-agnostic and can be wrapped in a Laravel test trait or a custom assertJsonMatches() helper in roughly a day.
- How do I install lchrusciel/api-test-case?
- Run composer require --dev lchrusciel/api-test-case and it works with the default configuration, with no service container changes and no production code. You then extend either JsonApiTestCase or XmlApiTestCase depending on your API format. Directories are guessed for you, using ../Responses relative to the test class and ../DataFixtures/ORM/ for fixtures. The documented TDD loop is: write the test, create the expected response file, watch it fail, implement the controller, watch it pass, refactor.
- Which Symfony and PHPUnit versions does ApiTestCase support?
- Support is version-banded and moves quickly: v5.3.0 dropped Symfony 5.4 and 6.1 through 6.3, v5.3.2 dropped 5.4 and added 6.4 and 7.0, and v5.3.3 added PHPUnit 11. Because the base class inherits both PHPUnit's TestCase and Symfony's WebTestCase, every upstream major is a potential breaking event, so always check the release notes before bumping your CI stack. If a PHPUnit upgrade lands before a matching package release, your test suite can be blocked on the maintainer's release cadence.
- How do the PHP-Matcher placeholders like @string@ work in expected response files?
- Expected-response files are plain JSON, but volatile values can be replaced with coduo/php-matcher patterns such as @string@, @integer@, or @[email protected](), plus a UUID matcher added in PR #149. That keeps ids, timestamps, and uuids from making golden-file tests brittle while still asserting on everything else in the body. It is the single most useful idea to borrow for any framework, including Laravel.
- What is the difference between assertResponse and Laravel's assertJson or assertJsonStructure?
- ApiTestCase compares the entire response body against a checked-in expected-response file and reports a real diff when it does not match. Laravel's assertJson and assertJsonStructure assert on fragments and shapes inline inside the test method. Full-body golden files are convenient but fail on cosmetic changes, key ordering, and JSON escaping; the ESCAPE_JSON flag exists purely for backwards compatibility and is slated for removal. Laravel's granular assertions are generally less fragile for teams that do not want snapshot maintenance.
- Do I have to use Alice and Doctrine fixtures with ApiTestCase?
- No, it is fully opt-in. Doctrine and Alice integration is gated behind the IS_DOCTRINE_ORM_SUPPORTED flag plus two bundles registered only in the test environment, so an app that uses neither fixtures nor Doctrine pays no cost. That gives the package a good decoupling score within Symfony projects. You can keep using your own fixture strategy and still get the response matching and diff output.
- How is ApiTestCase configured?
- Everything is configured through phpunit.xml <server> entries: KERNEL_CLASS, EXPECTED_RESPONSE_DIR, FIXTURES_DIR, TMP_DIR, OPEN_ERROR_IN_BROWSER, and ESCAPE_JSON. There are no service container changes, no production code, and no migrations to manage. Be careful with OPEN_ERROR_IN_BROWSER, which should never be true in a CI environment. Also note that the expected $client initialization expectations are largely undocumented, so read the base class if a test fails to boot.
- Is ApiTestCase safe to run in production?
- It is a dev dependency only, MIT licensed, and ships no runtime artifact, so the blast radius on production is effectively zero. Install it with --dev and keep all configuration in phpunit.xml. The real risk is not production impact but test-suite coupling: snapshot-style body comparisons plus upstream version churn can create maintenance overhead rather than runtime danger.
- What are the alternatives to ApiTestCase for Laravel JSON API testing?
- Laravel ships assertJson, assertExactJson, and assertJsonStructure, which cover most JSON API tests without any extra dependency. For matcher-style flexibility you can wrap coduo/php-matcher yourself or use a snapshot package such as spatie/phpunit-snapshot-assertions for response bodies. If you genuinely need ApiTestCase's feature set, you are better off porting the pattern into a small Laravel trait than trying to adapt the Symfony base class. On a Symfony or API Platform codebase, it remains a strong fit as a thin WebTestCase specialization.
- Is lchrusciel/api-test-case actively maintained?
- It is a single-maintainer-led open source project, originally from Lakion and now maintained by lchrusciel, with roughly 410 stars and very few reported dependents. That means low evidence of production hardening at scale and a genuine bus-factor risk, even though the README, changelog, and release cadence are healthy. Releases are reactive to upstream majors, which is exactly where a lone maintainer becomes a bottleneck. The escape hatch is friendly: expected responses are plain JSON, so a custom assertion helper can reproduce about 80 percent of the value if the package is abandoned.