Test Foundation Laravel Package

Product Decisions This Supports

• Build vs. buy for test infrastructure. The package's real product is not the PHP code but the encoded conventions: transaction-per-test isolation, factory states over raw values, story fixtures for fixed worlds, named test doubles, expectation classes for repeated checks, and a linter-like style guide for test bodies. A team deciding whether to write this scaffolding internally should compare the 1–2 weeks of senior-engineer time to codify and socialize those rules against adopting an opinionated baseline with a documented standard already attached.
• Standardizing test suites across a multi-package roadmap. For a DXP with separate packages (content, assets, translation, workflows), per-package test bootstrapping is a recurring tax and a source of drift. This package is scoped exactly to that problem — a shared, repeatable baseline — so it maps to a "one testing contract across N repositories" decision rather than a single-app decision.
• Codifying conventions as machine-actionable artifacts. The skills/opendxp-tests bundle means the testing standard ships as instructions an AI agent (and a new hire) can apply directly, not as a wiki page that rots. That is a legitimate roadmap input: if agent-assisted contribution is part of the delivery model, conventions need to be executable, and this is a cheap way to test that thesis.
• Onboarding and review-cost reduction. Opinionated defaults for environment, config layering (test.yaml plus EnvironmentTestCase for outliers), cleanup, and external-service skipping remove the "how do I set up a test here" conversation from every PR. This supports a decision to optimize for contributor throughput over contributor flexibility.
• Test-suite quality as a measurable goal. Rules like "one action per test," "no assertions before the action," "datasets change data, never course," and "no only()/dd() in the repository" are enforceable review criteria. That converts "improve our tests" from an aspiration into a checklist you can put in a definition-of-done.
• Ecosystem/platform strategy. Dependents = 0 and 1 star mean this is currently a first-party convenience, not a de facto standard. Treat it as a signal of where the platform vendor is investing, not as evidence the market has validated it.

When to Consider This Package

Adopt when all or most of these hold:

• You are building inside the OpenDXP ecosystem or deliberately mirroring its conventions, and the shared baseline is worth more to you than bespoke tooling.
• You maintain multiple packages or applications where test setup is duplicated and drifting.
• Your team is willing to accept opinionated defaults — Pest expectations over PHPUnit assertions, factories with states, stories in tests/Story/, named doubles in tests/Application/ — without relitigating them per repository.
• You want conventions that are portable to agent-assisted development, so contribution guidelines can be applied mechanically.
• You can pin a version and absorb churn, and you have at least one engineer who can read the source when documentation lags.

Look elsewhere when:

• You are writing a standalone Laravel app with no DXP domain needs — you'd be importing a dependency to get Testbench bootstrapping and a handful of traits you could write in an afternoon.
• Your team has already converged on its own Pest conventions; the overlap cost likely exceeds the benefit, and the style rules here conflict with habits you'd have to unwind.
• You need community support, third-party tutorials, or a hiring signal. With 1 star and 0 dependents, you are an early adopter with a direct line only to the maintainer — price in the support risk and the possibility of abandonment.
• You require PHPUnit-native reporting or integrations (custom listeners, existing CI dashboards) and cannot run Pest expectations.
• Your organization cannot accept single-vendor coupling to OpenDXP's release cadence; the testing layer becomes a hard dependency on the framework's timeline.
• You need hardened, versioned API stability. A package with one release date and no dependent ecosystem is pre-stability by observation, regardless of its version string.

Before committing: run a time-boxed spike — port one representative package's suite, measure the migration effort, confirm the browser/testkit commands work in your CI, and identify which rules your team would fight. If the spike doesn't show a clear win on setup time or review friction, the honest answer is to copy the SKILL.md rules into your own contributor guide and skip the dependency.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost bet on standardizing how we test, not a new capability we sell. The package encodes a testing discipline — isolation, fixtures, naming, one action per test — into reusable tooling, so every new package inherits the same baseline instead of re-inventing it. The upside is faster onboarding and less review churn across our package portfolio. The risk is concentration: it is an early-stage, single-maintainer library with essentially no external adoption, so we should treat it as an internal accelerator we pin, not a strategic dependency. Recommendation: pilot on one package, measure setup time and PR review cycles, and keep our own conventions documented independently so we can walk away cheaply.

For engineering: You get Testbench/PHPUnit bootstrapping, assertion helpers, fixtures, sane config/environment defaults, cleanup, and composable traits — plus a written style guide covering test structure, factories and stories, helper placement, test doubles, isolation, and formatting, packaged so an agent can apply it while writing tests. The trade-off is explicit: you accept the conventions as given, including Pest expectations over PHPUnit assertions and factories over raw model values. Adopt on the pilot package first; flag any rule that costs more than it saves, because that feedback is the thing most likely to shape whether this becomes a real standard or stays a one-team convenience.