In a Laravel feature test, how do you assert that issuing a refund queues a job and sends a mailable without running or sending either?

## What a fake is in Laravel Laravel ships **fakes** for the services that cause side effects: `Queue`, `Bus`, `Mail`, `Notification`, `Event`, `Http`, `Storage`, `Process` and `Exceptions`. Calling `Queue::fake()` does not stub one method: it **swaps the object behind the facade** for a recording object (`QueueFake`, `MailFake`, `BusFake` and so on) that keeps every job or mailable it receives in memory and exposes assertion methods. Because the swap happens in the container, your controller keeps calling `ProcessRefund::dispatch()` and `Mail::to()->send()` unchanged; it simply talks to the recorder. The order matters: **fake, act, assert**. A fake installed after the request has run records nothing. ## The refund test Suppose `POST /orders/{order}/refunds` creates a `Refund`, dispatches `ProcessRefund` (which calls the payment provider) and mails the customer a `RefundIssued` mailable. A feature test wants to prove the controller did both, without calling the provider or delivering mail. ```php Queue::fake(); Mail::fake(); $this->actingAs($user)->post("/orders/{$order->id}/refunds", ['amount' => 1500]); $refund = Refund::sole(); Queue::assertPushed(ProcessRefund::class, fn (ProcessRefund $job) => $job->refund->is($refund)); Queue::assertPushedOnce(ProcessRefund::class); Mail::assertSent(RefundIssued::class, fn (RefundIssued $mail) => $mail->hasTo($user->email)); ``` The closure form is the valuable part: asserting only the class proves *a* refund job was pushed, while the closure proves it carries **this** refund and goes to **this** customer. ## `Queue::fake()` versus `Bus::fake()` | | `Queue::fake()` | `Bus::fake()` | |---|---|---| | What it replaces | the queue manager | the job dispatcher | | Records | jobs pushed to a queue, i.e. `ShouldQueue` jobs, plus queued mail, notifications and listeners | every `dispatch()`, `dispatchSync()` and after-response dispatch | | Main assertions | `assertPushed`, `assertPushedOn`, `assertPushedTimes`, `assertNothingPushed` | `assertDispatched`, `assertDispatchedSync`, `assertChained`, `assertBatched` | | A job **without** `ShouldQueue` | runs immediately, is not recorded | recorded, not run | The last row is the usual surprise. The bus dispatcher only sends a job to the queue when it implements `ShouldQueue`; otherwise it calls `handle()` on the spot. Under `Queue::fake()` such a job therefore **executes** and `assertPushed` fails. `Bus::fake()` intercepts earlier, at the dispatcher, so it records both kinds. Both fakes accept a list to fake only some classes (`Queue::fake([ProcessRefund::class])`) and an `except()` to leave some real. ## Sent versus queued mail `MailFake` keeps two lists. A mailable that implements `ShouldQueue`, or one passed to `Mail::queue()`, lands in the **queued** list even when the code called `send()`. So: - `Mail::assertSent()`, `assertSentOnce()`, `assertNotSent()` and `assertNothingSent()` look at mail sent synchronously. - `Mail::assertQueued()`, `assertQueuedOnce()` and `assertNothingQueued()` look at queued mail. - `Mail::assertNothingOutgoing()` covers both. When `assertSent()` fails while something was queued, its failure message ends with a hint to use `assertQueued()` instead. `Notification::fake()` follows the same idea with `Notification::assertSentTo($user, RefundIssuedNotification::class)`. ## What the fakes do not cover 1. **The job's own logic.** The fake proves the controller *asked* for the work. Test `ProcessRefund::handle()` in its own test by constructing the job and calling it, with the payment client faked there. 2. **Serialization.** A fake stores the live object, so a job whose payload cannot be serialized still passes. `Queue::fake()->serializeAndRestore()` round-trips each job through serialization to catch that. 3. **Things other code does for real.** Without fakes, the skeleton's `phpunit.xml` already sets `QUEUE_CONNECTION=sync` and `MAIL_MAILER=array`, so jobs run inline and mail goes to an in-memory transport. That keeps tests off the network but gives you nothing to assert on and runs the payment job for real, which is exactly what the fakes prevent. ## Narrower fakes and the unhappy path A test does not have to fake everything. `Queue::fake([ProcessRefund::class])` records only that job and lets every other queued job behave as configured, which keeps unrelated jobs from silently disappearing. `Queue::fake()->except([AuditLog::class])` inverts the list. `Bus::fake()` takes the same kind of list. The negative case deserves its own test. A refund above the order total should be rejected, and the proof is the absence of side effects: ```php Queue::assertNothingPushed(); Mail::assertNothingOutgoing(); ``` When an assertion helper does not fit, the fakes expose the raw records: `Queue::pushed(ProcessRefund::class)` and `Mail::sent(RefundIssued::class)` return collections you can inspect directly, and `Mail::assertSentCount()` or `Queue::assertCount()` check totals. ## Common mistakes - Asserting only the class name, so a refund for the wrong order still passes. - Using `Queue::assertPushed` for a job that lacks `ShouldQueue`. - Using `assertSent` for a mailable that implements `ShouldQueue`. - Faking after the request, then wondering why nothing was recorded.