Peridot Expect Plugin Laravel Package

Product Decisions This Supports

• Test-suite readability as a velocity lever. This plugin adds expect($value)->to->be->equal(...)-style matchers to Peridot, the PHP BDD/spec framework. The product value is indirect: more expressive specs mean tests read like acceptance criteria, which shortens onboarding, makes code review of test intent faster, and turns specs into lightweight living documentation of business rules.
• Build vs. buy for developer tooling. Adopting it is effectively "buy" at zero cost (MIT): a composer require in require-dev instead of writing and maintaining bespoke assertion helpers and matcher extensions. The PM decision is whether engineering time is better spent on custom test utilities or on product work.
• Roadmap sequencing for the test platform. Choosing this plugin implicitly commits to keeping Peridot in the stack. That feeds a real roadmap decision: invest in Peridot modernization (this plugin, matcher library, CI polish) versus fund a migration to PHPUnit or Pest (which already ships expect() natively and dominates ecosystem mindshare). This package's existence is a signal that the "stay on Peridot" path has a viable DX story, but only a thin one.
• Legacy maintenance and LTS scoping. If any product line or long-lived branch still runs Peridot suites, this plugin informs whether those branches get continued test-tooling support or are frozen while new work moves to a modern framework.
• Use cases it actually serves: BDD-style spec suites, mapping specs to business rules for stakeholder-readable behavior docs, and teams already fluent in RSpec/Jasmine idioms who want the same ergonomics in PHP.

When to Consider This Package

Consider it when all of the following hold:

• Peridot is already your test framework, or you've inherited a Peridot suite you must keep green.
• You want a low-effort DX uplift (expressive matchers, less assertion boilerplate) without rewriting existing specs.
• Your team is comfortable with expectation-style DSLs and values spec readability over tooling breadth.
• You accept that this is a tactical convenience, not a platform investment.

Look elsewhere when:

• Greenfield work. Use Pest (native expect() plus a large ecosystem, active maintenance, IDE/static-analysis support) or PHPUnit (org default, universal tooling). Do not start a new suite on Peridot.
• You need maintenance guarantees. One star and zero dependents means no community safety net and a near-certain single-maintainer bus factor. If security patching, PHP-version support, or vendor SLAs matter, this is the wrong layer to depend on.
• CI/observability integration matters — coverage reporting, IDE test runners, mutation testing, and static analysis all have far richer support in the mainstream frameworks.
• Your org standardizes on PHPUnit for hiring, tooling, or compliance reasons; introducing a second assertion idiom fragments the codebase.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed add-on that makes our PHP tests more readable, which speeds onboarding and reduces the chance of defects slipping through review. Cost is essentially zero and it's isolated to development dependencies, so it carries no runtime or customer-facing risk. Treat it as a tactical quality-of-life improvement, not a strategic platform bet — it has no support contract and a very small user base (1 star, 0 dependents), so we should not build a multi-year dependency on it.

To engineering: The plugin brings expect()->to->be matchers to Peridot, cutting custom assertion boilerplate and making specs read closer to plain English. Adoption is a dev-dependency plus a small config change, fully reversible, and test-only in scope. Two caveats: it's effectively unmaintained, so pin the version and be prepared to vendor it; and if Peridot is strategically important to us, we should pair this with a scoped evaluation of migrating to Pest or PHPUnit, which offer equivalent ergonomics with active ecosystems.