- Is litvinab/rest-api-test a Laravel package?
- No. Despite the Laravel/PHP framing, it is a Symfony bundle built around Symfony's bundle registration contract, dependency injection extensions, KernelTestCase and WebTestCase, and Doctrine for fixtures. Laravel does not implement the Symfony bundle contract, and the package provides no service provider, config file, or Laravel test-case integration.
- Can I install litvinab/rest-api-test in a modern Laravel app with Composer?
- Almost certainly not. Its last release was 2019-09-10 and it is expected to constrain symfony/* to ^3.4 or ^4.x and PHP to 7.1-7.4, while modern Laravel pulls Symfony components at ^6 or ^7. Because those version sets do not intersect, composer require should fail outright rather than degrade gracefully.
- Which Laravel versions are supported by litvinab/rest-api-test?
- None officially. The repository contains no Laravel service provider, configuration file, or Laravel test-case base class. Any use in a Laravel suite would require rewriting the package's base classes and wiring, which is where most of its value lives.
- What PHP versions does litvinab/rest-api-test support?
- It targets the PHP 7.1-7.4 era. On PHP 8.2 and later, the untyped properties and assertion signatures are likely to produce deprecations or fatal errors, and there has been no release in roughly six years to address that. Treat PHP 8.2+ as unsupported unless you fork and test it yourself.
- Does litvinab/rest-api-test work with Laravel's HTTP testing helpers such as $this->json()?
- No. It is designed around Symfony's KernelTestCase and WebTestCase, which is a different abstraction from Laravel's HTTP testing surface. Laravel's $this->json(), RefreshDatabase, and model factories already cover the same functional testing use cases without this package.
- Does litvinab/rest-api-test provide fluent status, header, and JSON structure assertions?
- Yes in concept: the package advertises fluent assertions for status codes, headers, JSON bodies, and nested response structure validation. Those helpers are Symfony-oriented, though, and Laravel already provides assertStatus, assertHeader, and assertJsonStructure in its first-party testing API. The readable chaining idea is useful, but the implementation is not a drop-in for Laravel.
- Is litvinab/rest-api-test actively maintained?
- No meaningful maintenance signals are present. It has about 2 stars, 0 dependents, no release since 2019, no clear maintainer response path, and no CVE coverage. For test infrastructure, that means you would own the risk and any fixes.
- What are the best alternatives to litvinab/rest-api-test for Laravel API testing?
- Use Laravel's built-in HTTP testing API with $this->json(), assertStatus, assertHeader, and assertJsonStructure, backed by model factories and RefreshDatabase for fixture-driven tests. A shared tests/Concerns trait can wrap auth and common header assertions. For acceptance testing, Behat with a custom Laravel context is a practical option.
- Should I fork litvinab/rest-api-test to reuse its REST assertion helpers?
- Only as a reference implementation or specification. The useful pattern, fixture-driven functional tests with reusable REST assertion helpers and seed/teardown commands, can be reimplemented on Laravel's testing API in roughly one to two developer-weeks. A fork turns a dormant dependency into an owned asset with a permanent maintenance budget and requires Symfony bundle expertise.
- Is litvinab/rest-api-test safe to use in production?
- It is a require-dev-only concern, so it never ships to production and exposure is confined to CI and the developer toolchain. The practical failure mode is blocked merges during PHP, Laravel, or Symfony upgrades rather than a customer-facing incident. That lowers blast radius but does not make it a safe long-term choice for test infrastructure.