extend(TestCase::class) ->use(RefreshDatabase::class) ->in('Feature'); /* |-------------------------------------------------------------------------- | Expectations |-------------------------------------------------------------------------- | | When you're writing tests, you often need to check that values meet certain conditions. The | "expect()" function gives you access to a set of "expectations" methods that you can use | to assert different things. Of course, you may extend the Expectation API at any time. | */ expect()->extend('toBeOne', function () { return $this->toBe(1); }); /* |-------------------------------------------------------------------------- | Functions |-------------------------------------------------------------------------- | | While Pest is very powerful out-of-the-box, you may have some testing code specific to your | project that you don't want to repeat in every file. Here you can also expose helpers as | global functions to help you to reduce the number of lines of code in your test files. | */ function something() { // .. } /** * Bind fake provisioning services into the container and return them so a test * can script/inspect SSH, WireGuard, Proxmox, DNS and Traefik interactions. * * @return array{shell: \App\Services\Ssh\FakeRemoteShell, hub: \App\Services\Wireguard\FakeWireguardHub, pve: \App\Services\Proxmox\FakeProxmoxClient, dns: \App\Services\Dns\FakeHetznerDnsClient, traefik: \App\Services\Traefik\FakeTraefikWriter} */ function fakeServices(): array { $shell = new \App\Services\Ssh\FakeRemoteShell; $hub = new \App\Services\Wireguard\FakeWireguardHub; $pve = new \App\Services\Proxmox\FakeProxmoxClient; $dns = new \App\Services\Dns\FakeHetznerDnsClient; $traefik = new \App\Services\Traefik\FakeTraefikWriter; $monitoring = new \App\Services\Monitoring\FakeMonitoringClient; app()->instance(\App\Services\Ssh\RemoteShell::class, $shell); app()->instance(\App\Services\Wireguard\WireguardHub::class, $hub); app()->instance(\App\Services\Proxmox\ProxmoxClient::class, $pve); app()->instance(\App\Services\Dns\HetznerDnsClient::class, $dns); app()->instance(\App\Services\Traefik\TraefikWriter::class, $traefik); app()->instance(\App\Services\Monitoring\MonitoringClient::class, $monitoring); return ['shell' => $shell, 'hub' => $hub, 'pve' => $pve, 'dns' => $dns, 'traefik' => $traefik, 'monitoring' => $monitoring]; } /* | Shared account helpers. Defined here — NOT in an individual test file — so a | targeted run (pest tests/Feature/Admin/OneFile.php) still resolves them. */ function operator(string $role): App\Models\User { return App\Models\User::factory()->operator($role)->create(); } function admin(): App\Models\User { return App\Models\User::factory()->create(['is_admin' => true]); } /** * Undo the mailbox-seeding migration's baseline, for tests written before it. * * RefreshDatabase migrates once per run, not once per test, so every test * starts from a transaction rolled back to that migrated state — including the * five mailboxes (no-reply, support, billing, office, info) and all five * mail.purpose.* settings the mailbox-seeding migration writes. The tests in * tests/Feature/Mail predate that migration: several create their own mailbox * under one of those same five keys, which now collides with mailboxes.key's * unique constraint; a couple rely on a purpose being genuinely unset to prove * MailboxResolver's system fallback, which the seeded mapping would otherwise * pre-empt. Call this from such a file's beforeEach() to restore the blank * slate it was written against. */ function clearMailboxSeed(): void { App\Models\Mailbox::query()->delete(); foreach (App\Services\Mail\MailPurpose::ALL as $purpose) { App\Support\Settings::set(App\Services\Mail\MailPurpose::settingKey($purpose), null); } }