Phpunit Extras Laravel Package

Product Decisions This Supports

• Faster Time-to-Market for Tarantool Features: Reduces test development time for PHP applications interacting with Tarantool by providing specialized PHP attributes, expectations, and mocking utilities. This directly supports sprints focused on database-driven features (e.g., caching layers, real-time data processing).
• Risk Mitigation for Database Integrations: Enables comprehensive testing of Tarantool-specific edge cases (e.g., Lua/SQL execution, version compatibility) to prevent production incidents tied to database interactions. Critical for teams adopting Tarantool as a primary or secondary data store.
• Build vs. Buy Decision: Justifies using this package over custom test utilities by offering maintained, Tarantool-optimized assertions (e.g., request mocking, prepared statement validation) that align with the Tarantool PHP client ecosystem. Avoids technical debt from reinventing the wheel for niche use cases.
• Ecosystem Viability Signal (New in v0.3.0): The 0.3.0 release (PHP 8.2+, PHPUnit 10, modern PHP attributes) shows the package is actively maintained again after a long gap since 2022. This materially de-risks the "abandoned dependency" concern that previously argued against adoption — but it also signals the API surface is still pre-1.0 and may continue to shift.
• Key Use Cases:
  • API Backends: Validate Tarantool-backed endpoints (e.g., EVALUATE requests, space operations) with minimal boilerplate.
  • Data Pipeline Testing: Simulate Tarantool responses for ETL jobs or migration scripts to catch SQL/Lua errors early.
  • Performance Testing: Mock Tarantool latency or failures to stress-test resilience without impacting production instances.
  • Multi-Version Support: Test compatibility across Tarantool versions using attribute-based requirements (e.g., #[RequiresTarantool('^2.3.2')]).
  • Security Audits: Verify Lua/SQL injection safeguards by testing malformed requests via mock clients.
  • Modern PHPUnit Alignment: Drop-in fit for teams already standardized on PHPUnit 10 attributes (e.g., #[DataProvider], #[Group]) — no mixing of annotation and attribute styles.

When to Consider This Package

• Adopt if:
  • Your PHP application directly interacts with Tarantool (e.g., via the official client) for core functionality (data storage, caching, or real-time sync).
  • You need to test Tarantool-specific logic (e.g., Lua scripts, SQL queries, prepared statements) without spinning up a real instance for every test.
  • Your stack is on PHP 8.2+ and PHPUnit 10 — these are now hard requirements as of v0.3.0, not optional targets.
  • Your team values developer productivity over minimal test setup, as PHP attributes (Lua/SQL setup, requirements) reduce repetitive code for common scenarios.
  • You require conditional test execution (e.g., skip tests if the Tarantool version is unsupported or a Lua condition fails).
  • Your CI/CD pipeline can tolerate dev dependencies (this package is require-dev only).
• Look elsewhere if:
  • You’re not using Tarantool—this package is tightly coupled to its ecosystem (e.g., no support for Redis, PostgreSQL, or other databases).
  • Your tests are trivial (e.g., basic HTTP assertions) and don’t involve Tarantool-specific interactions.
  • Your project cannot upgrade to PHP 8.2+ / PHPUnit 10. v0.3.0 is a breaking upgrade: v0.2.1 was the last version supporting older PHP/PHPUnit, so you either pin to 0.2.x (now effectively unmaintained) or absorb a dependency upgrade.
  • You are migrating an existing test suite written with annotations (@lua, @sql, @requires Tarantool ^x.y.z). All of these are removed and replaced by attributes in v0.3.0 — budget a mechanical-but-project-wide refactor of every Tarantool test file.
  • You prefer zero-configuration testing and are unwilling to extend TestCase or configure PHPUnit extensions.
  • You need enterprise-grade support / production SLA—the package remains low-adoption (single-digit stars, few dependents) and is still 0.x.
  • Your team lacks familiarity with PHPUnit extensions or Tarantool’s Lua/SQL syntax.

How to Pitch It (Stakeholders)

For Executives: "This package lets our PHP team test Tarantool integrations faster and more reliably. By using modern PHP attributes and mock clients, we can validate database logic—like caching layers or real-time queries—without spinning up expensive Tarantool instances for every test. The new 0.3.0 release shows the project is actively maintained and current with PHP 8.2 and PHPUnit 10, which de-risks the 'abandoned dependency' concern we flagged before. It reduces bugs in production and accelerates delivery for data-heavy roadmap items like [X feature]. The MIT license and dev-only footprint keep operational overhead low — the cost is a one-time test-suite migration to attributes, not a runtime change."

For Engineering/DevOps: *"v0.3.0 is a breaking upgrade, but a straightforward one:

• Attributes replace annotations: @lua / @sql setup and @requires Tarantool ^2.3.2 are gone — the equivalents are now PHP attributes, so tests match the PHPUnit 10 idiom (#[DataProvider], #[Group]). Mechanical migration across test files, no runtime path changes.
• Hard floor of PHP 8.2+ and PHPUnit 10: align the CI matrix and composer.json before bumping; if any service is still on 8.1, do the PHP upgrade first or pin to 0.2.x deliberately.
• Mock Tarantool responses to test error handling or edge cases without a real server.
• Attribute-driven setup to seed test data or preconditions in one line, with no repeated SQL/Lua blocks.
• Version-aware tests with Tarantool requirements to catch compatibility issues early. It’s a drop-in for teams already using the Tarantool PHP client. Tradeoff: dependency upgrades plus a one-pass test refactor, but real payoff for complex database interactions."*

For QA/Testing Teams: *"This package cuts test development time for Tarantool by:

1. Automating setup/teardown via attributes so you don’t repeat SQL/Lua in every test — note the syntax changed in 0.3.0, so pull the updated docs when migrating existing cases.
2. Validating request patterns (e.g., expectSelectRequestToBeCalledOnce()) to ensure your PHP code interacts with Tarantool as expected.
3. Isolating tests with mock clients to avoid flaky tests from network issues or shared Tarantool instances. Perfect for validating APIs, migrations, or performance scenarios where Tarantool is critical. Plan for a sweep of existing annotation-based tests as part of the 0.2.x → 0.3.0 upgrade."*