Repository navigation
Testing
composer install
composer test
composer lintTests are authored in Pest. Orchestra Testbench supplies a Laravel test application with UUID recipient models; PHPUnit is only Pest's underlying dependency. Provider communication is mocked, including contract tests through the actual installed FCM/APNs channel classes. No live Apple/Google credential is required.
Coverage includes encryption/hidden tokens, registration uniqueness, ownership/reassignment/rotation/removal, application/environment isolation, recipient history cardinality, event idempotency/retention, preference semantics, after-commit creation, rollback, identity-only queued jobs, immediate sends, per-device retry isolation, current eligibility, stale invalidation protection, expiration, bounded retries, throttling, queue-outage recovery, cleanup and provider acceptance semantics.
A two-connection file-backed SQLite test attempts token/owner changes, cancellation, preference changes and duplicate processing while a provider callback is active. Those writes fail under the transaction lock, then succeed after commit. Reentrant duplicate processing also observes the processing state and does not submit again. This establishes the tested SQLite boundary; it does not establish a real-device guarantee or prove other engines' lock behavior without testing them.
Resolve/test both Laravel majors rather than only checking Composer declarations:
composer update --with 'laravel/framework:^12.0' --with 'orchestra/testbench:^10.0'
composer test
composer update --with 'laravel/framework:^13.0' --with 'orchestra/testbench:^11.0'
composer testThe 0.9.0 source candidate was revalidated: 47 Pest tests / 200 assertions pass on Laravel 12.71.0 and 13.40.0 with PHP 8.4.27 and 8.5.12. FCM 6.2.0 and APN 6.5.0 are the resolved stable transport packages. Composer validation and Pint PSR-12 checks also pass. No CI workflow or production deployment has been configured by this package.
Run these with both supported PHP minor lines and a current security patch. Run formatting and Composer validation after source changes. Test the actual production database engine and queue driver in the consuming application's integration environment. Do not mistake SQLite unit tests for a Redis/database queue deployment check.
Not verified. No Android/iOS device receipt, display or tap handling is established by the automated provider-mocked tests. The procedure below must be run with actual app builds, devices, credentials and operational workers before a production delivery claim.
- Install the reviewed package into a production-like Laravel application. Publish configuration/migration, use UUID users, configure durable queues, recovery and cleanup.
- Prepare one real Android device with its correct FCM project and one real iPhone with its APNs bundle/team/environment. Also prepare a second device for at least one account.
- Install app builds with permission prompts, authenticated registration, token refresh, local presentation where applicable and tap routing. Record app/OS/package versions and build distribution method.
- Configure provider credentials through secret storage; verify outbound provider connectivity. Keep tokens and private keys out of evidence/logs/screenshots.
- Create a test account and register each installation. Verify ownership, transport, generation and safe fields through authorized tooling.
For each case send a fresh event key and stable notification UUID, and record the four observations below independently.
- Foreground: receive/process the message and show at most one alert according to the app's presentation policy.
- Background: verify transport receipt and actual OS presentation, not merely server acceptance.
- Terminated: test a normal terminated state where the OS supports delivery; separately record force-stop/force-quit restrictions and avoid claiming delivery in unsupported states.
- Permission denied: history remains available; do not infer display from provider acceptance. Enable permission in settings, reopen/reconcile registration, and send a new event.
- Token refresh: update the same installation, observe generation advance, and verify stale jobs skip while a new event targets the replacement token.
- Logout: unregister before session invalidation; pending work becomes ineligible. Switch users through the explicit authorized flow and verify old-account work is not submitted to the new owner.
- Multiple devices: verify one visible history record and independent device intents. Make one provider submission fail transiently; only that intent may retry.
- Provider rejection: test a safely controlled invalid token/credential condition. Verify correct error classification, bounded retry behavior and generation-safe invalidation without publishing credentials/tokens.
- Tap handling: tap alerts from foreground/background/launch states, route to the intended authenticated screen, validate deep links, and avoid duplicate navigation/presentation.
- Queue outage: stop enqueue availability after message creation, restore it, run recovery and verify pending work is eventually attempted without duplicating history.
- Deletion: delete visible history before a pending attempt, run any queued job and verify no new provider submission occurs. Accepted/in-flight submissions cannot be recalled.
For every platform/case record a safe test identifier, event/notification UUID, package/app/OS versions, timestamps and:
- Provider accepted submission: yes/no/unknown, with safe server state.
- Device received message: observed/not observed/unknown, with client-side evidence.
- Operating system displayed alert: observed/not observed, including permission/state conditions.
- User opened/tapped: observed/not tested, including destination and authentication behavior.
Keep failed and inconclusive cases explicit. Receipt acknowledgment is deferred; use controlled client instrumentation for smoke evidence without presenting it as a package receipt feature. Record results in the consuming application's private test records and publish only sanitized package-level evidence.
Moztopia Notifications
One notification per recipient. Independent delivery to every device.
Documentation · Source · Report an issue · MIT License
© 2026 Moztopia. Distributed under the MIT License.
