Rest Api Test Laravel Package

Getting Started

Start with the stack reality, not the install. This repository is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/ publish step, and no Laravel test-case base class. It depends on Symfony's KernelTestCase/WebTestCase, the config/bundles.php registration contract, and (for fixtures) Doctrine. In a modern Laravel app, composer require --dev litvinab/rest-api-test will fail on constraint resolution — the 2019 release targets symfony/* 3.4/4.x and PHP 7.1–7.4, while Laravel 10/11 pull Symfony 6/7 on PHP 8.2+. There is no intersection.

So "getting started" for a Laravel developer means one of two paths:

• Legacy Symfony app (the only real install path):

  1. composer require --dev litvinab/rest-api-test
  2. Register in config/bundles.php for test env only: Litvinab\RestApiTest\RestApiTestBundle::class => ['test' => true]
  3. Read the base test-case class and the console commands in src/, extend the base class in a smoke test, and run one fixture-driven endpoint test.

• Laravel app (the likely case): adopt the pattern, not the package. Read the base test cases and the fixture-loading commands for ~1 day, then reimplement the useful 10% on top of Illuminate\Foundation\Testing\TestCase. That is the day-to-day leverage.

Where to look first: the base test-case classes and the console commands — that's where the entire value of the repo lives. The bundle wiring is incidental. First use case to reproduce: a single protected JSON endpoint test with one seeded fixture, one HTTP call, and structural assertions on the response.

Implementation Patterns

The one pattern worth extracting is the test shape: fixture in → request with auth/headers → chainable response assertions out. Everything else is Symfony glue you will discard.

• Standard test shape — each test has three phases: load a deterministic fixture, issue a typed request (getJson/postJson/putJson/…), assert status + JSON structure + payload. In Laravel this becomes RefreshDatabase + a model factory in setUp (or a dedicated fixture method), then $this->getJson(...)->assertOk()->assertJsonStructure([...]). The package's contribution is the convention, not the code.

• Auth and header setup — the package centralizes auth headers so tests don't repeat token boilerplate. In Laravel, replicate this with a trait: an actingAsApiUser() helper that sets Authorization via $this->withToken(...) or $this->actingAs($user, 'api'), plus a withJsonHeaders() for Accept/Content-Type. Keep it in tests/Concerns/ so every API test inherits the same contract.

• Fixture loading as a command — the package ships console commands to seed and tear down fixtures for acceptance runs. In Laravel, the equivalent is an Artisan command (or a FixtureSeeder class) invoked from a Behat context or from setUp. Prefer Laravel's factory + seeder layer unless you specifically need cross-test shared fixtures.

• Behat acceptance integration — if you run Behat against a Laravel API, model the context after the package's split: a request step, an auth step, a JSON-assertion step, and a fixture-reset hook (@beforeScenario). Keep assertion helpers as traits shared between PHPUnit and Behat contexts so both suites speak the same vocabulary.

• Assertion helpers — extract the package's "assert JSON structure" and "assert payload value" helpers into a trait (AssertsJsonApi) and reuse across feature tests. This is where chained readability comes from; it's 50–100 lines of code you would otherwise write inline on every test.

Gotchas and Tips

• The framework mismatch is the gotcha. Anything in the README or package code that references KernelBrowser, bundle config, or Symfony console won't port line-for-line. Confirm the target stack before spending a spike — a Laravel team should budget hours reading the source, not days trying to install it.

• Fixture leakage will bite you more than the package will. Fixture-driven suites that reload data per test go superlinear in CI. In Laravel, wrap every test in RefreshDatabase (transactional) and load shared fixtures once per class with setUpBeforeClass only if the ORM supports clean rollback. The 2019 package assumes serial Symfony runs and does not address parallel workers — if you parallelize with Paratest, use per-worker databases.

• PHP 8.x will emit fatals, not warnings, from PHP 7.1–7.4-era code (untyped properties, assert* signatures, KernelTestCase reflection). If you fork, pin to your PHP matrix and run PHPStan/Larastan on the vendored source before the first merge. Test-only deps still break CI on minor upgrades.

• Debugging install/registration failures: if the bundle is registered for the wrong env (e.g. all), it loads in prod and can interfere with the container; always register with ['test' => true]. If KernelTestCase fails to boot, check APP_ENV=test is exported and the cache is cleared (bin/console cache:clear --env=test).

• No maintainer, no upgrade path. There is no issue triage and no security response. If you fork, assign a named owner — unfunded forks rot silently and block CI on the next PHP upgrade. Treat the repo as a design reference, not a require-dev entry you'd defend in a supply-chain review.

• Extension points that actually matter if you fork: the base test-case class (override setup/assertions), the fixture console command (replace with a Laravel Artisan command or Behat @beforeScenario hook), and the assertion helper methods (port into a trait). Skip the bundle class and the DI extension entirely — you don't need them in Laravel.

• Don't let "it works in one test" fool you. CI passing once doesn't validate the pattern; validate it under parallel workers, under --order-by=random, and after an upgrade to the next PHP minor. That's the bar a test-scaffolding dependency has to clear, and this one hasn't been made for years.