Novaunit Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel test coverage. Nova is a paid, closed-source admin layer; asserting on resources, fields, actions, filters, lenses, and metrics normally means hand-rolling tests against internals or leaning on brittle browser checks. NovaUnit packages those assertions as a require-dev PHPUnit extension. This converts a vague backlog item ("we should really test the admin panel") into a concrete, schedulable choice: adopt it, fork it, or budget engineering days to build equivalents in-house.
• Definition of Done for Nova-facing work. "Done" on admin features becomes an automatable bar — field configuration, validation rules, authorization predicates, action side effects, computed values — rather than a manual QA script that expires with the person who wrote it. That is a scope decision with a cost attached, not just a tooling preference.
• Upgrade gating on the roadmap. Nova, Laravel, and PHP majors are the highest-risk recurring events for an admin panel that ops and support touch daily. A NovaUnit-backed suite turns "will this upgrade break internal workflows?" into a green/red signal, which tells you when to schedule the upgrade and how much buffer to reserve — instead of committing to a date on optimism.
• Test-stack modernization sequencing. Release 3.1.0 explicitly targets PHP 8.2 / Laravel 10 / PHPUnit 10, including PHPUnit 10's changed lifecycle (static data providers, setUp(): void, attributes over annotations). Adopting it no longer forces a PHPUnit 9 pin or a split CI matrix, so admin coverage can run alongside a framework upgrade rather than queued behind it — neither becomes a reason to delay the other.
• Where to spend QA capacity. Value scales with custom Nova surface area. Teams with heavily customized resources, actions, and authorization logic get outsized return; teams running stock CRUD get almost none. That is a prioritization input for limited test-writing time.
• Dependency risk register — revised signal. Still a single-maintainer package (63 stars, 0 dependents), so it lands in the "adopt with an exit plan" bucket. But the maintainer did the non-trivial port to PHPUnit 10's lifecycle and to Laravel 10, which is evidence of a live maintenance pulse as of the last release (Feb 2023). Risk shifts from "possibly abandoned" to "low bus factor, currently alive." Blast radius is a blocked pipeline, never a production outage — this is dev-only.
• CI budget and coverage scope. It defines what "tested" means for admin surfaces, so coverage targets and CI runtime get scoped realistically (these tests are fast — no HTTP bootstrapping) rather than aspirationally. Note the upstream constraint that gates all of it: Nova resolves through an authenticated Composer repository, so runners need credentials or a mirrored registry before any of this executes.

When to Consider This Package

Consider it when:

• Nova is a first-class part of the product — ops, support, or internal users run real business workflows through it, not a throwaway CRUD screen.
• You have custom resources, fields, actions, filters, lenses, or metrics carrying real logic (validation, authorization, side effects, computed values) and effectively zero automated coverage today.
• A Nova major upgrade or a PHP/Laravel upgrade is on the near-term roadmap and you want a behavioral safety net in place first, so the upgrade carries a roll-forward/roll-back signal.
• Your stack is already PHPUnit-based Laravel tests. NovaUnit extends PHPUnit and Laravel's test case, so adoption is incremental — no new framework, no new runner, no new CI primitive.
• You are on the supported matrix (PHP 8.2 / Laravel 10 / PHPUnit 10), which is the combination most likely to go green on the first run.
• You can pin the Nova version in Composer and tolerate a slow-moving dev dependency, provided every package-specific call is funneled through a project-local NovaTestCase base class so a fork or replacement is a one-file change.

Look elsewhere or deprioritize when:

• You are not on Nova, or use it only for stock CRUD — ordinary Laravel feature tests against models and policies cover most of the real risk.
• Your Nova code is thin glue with no custom validation, authorization, or action logic. The suite would mostly assert that your own source file says what it says — change-detection, not risk reduction.
• You are on Nova 5+ or PHP 8.3+/Laravel 11+ with no appetite for a timeboxed spike. 3.1.0 is explicit about Laravel 10 and silent about newer Nova majors; treat support as unproven.
• You cannot get Nova into CI. Without credentials or a mirrored registry, this buys local-only testing and the adoption case weakens considerably.
• You need vendor-backed support, a published roadmap, or an SLA. At 63 stars, zero dependents, and one maintainer, you are assuming ownership of the exit path by definition.
• Your team is still mid-migration across PHPUnit 10's lifecycle changes. Porting a 2.x-style suite across that boundary is real migration work, not a version bump — sequence it honestly.

How to Pitch It (Stakeholders)

For executives: Our admin panel is a paid, closed-source layer that operations and support depend on daily, and today it has essentially no automated safety net — coverage depends on someone remembering to click through screens. This is a small, free (MIT), dev-only testing toolkit that lets our existing test suite assert on Nova resources, fields, actions, filters, and permissions directly. The measurable outcome is not code coverage percentages; it is that Nova/Laravel upgrades stop being open-ended risk events with a calendar date picked on optimism and become a green/red signal. Cost is a few engineering days to stand up a pilot plus CI credential plumbing for Nova's authenticated Composer repo. Risk is contained by construction: it is a require-dev dependency, so the worst case is a blocked build, never a production incident — and we contain the exit by routing all usage through one project-local base class.

For engineering: This is a require-dev PHPUnit extension, not a runtime dependency. It gives us mock helpers and fluent assertions for resources, fields, actions, filters, lenses, cards, and tools without booting a browser or an HTTP request through Nova. Plan the adoption in this order: (1) verify the version floor against our lockfile — 3.1.0 targets PHP 8.2 / Laravel 10 / PHPUnit 10, and Nova 5+ is unverified, so spike before writing tests we intend to keep; (2) create one NovaTestCase base class first — that single file is what makes a fork or replacement a contained afternoon instead of a suite-wide rewrite; (3) write one resource-shape test and run it against our actual Nova version as the go/no-go signal; (4) then expand to the assertions that actually pay off — validation rules, authorization role matrices, resolve() output, and action side effects. Keep mocks for configuration and real objects for behavior; mocks never execute field logic. Mirror app/Nova/ in tests/Nova/ for an instant coverage diff, isolate these as their own fast suite gated on PRs touching app/Nova/**, and seed one deliberate regression during the pilot to prove the suite can go red — a green suite that cannot fail is worse than none. Expect API name drift between majors and read src/ rather than blog posts when a method "doesn't exist."