In a Laravel test, how do you move the clock forward to check that a refund request window closes after 14 days?

## Why tests need a controllable clock Business rules like "refunds may be requested within 14 days of delivery" depend on the current time. A test that waits two weeks is impossible, and a test that fakes dates by editing rows is fragile. Laravel's base test case includes the `InteractsWithTime` trait, which moves the application's clock. ## The helpers | Helper | What it does | |---|---| | `$this->travel(15)->days()` | move forward 15 days from now; units run from `microseconds()` to `years()`, and a negative number moves back | | `$this->travelTo($date)` | jump to an exact moment | | `$this->freezeTime()` | pin the current instant and return it | | `$this->freezeSecond()` | pin the start of the current second | | `$this->travelBack()` | return to real time | Each of `travel`, `travelTo`, `freezeTime` and `freezeSecond` accepts an optional **closure**: the closure runs at the chosen time, then real time resumes and the closure's result is returned. ## How it works Every helper ends in `Carbon::setTestNow($date)`. Carbon is the date library behind Laravel's `now()` and `today()` helpers, `Illuminate\Support\Carbon::now()`, and Eloquent's timestamps. Once a test time is set: - `now()` returns that instant, and it **does not advance**. Travelling fixes the clock at the new moment; two calls a second apart return the same value. - `created_at` and `updated_at` written by Eloquent use it. - Code that compares against `now()`, for example `$order->delivered_at->diffInDays(now())`, sees the travelled date. During teardown the base test case calls `Carbon::setTestNow()` with no argument (and the same for `CarbonImmutable`), so a forgotten `travelBack()` does not leak into the next test. ## The refund-window test ```php $order = Order::factory()->delivered()->create(); $this->travel(15)->days(); $this->actingAs($order->customer) ->post("/orders/{$order->id}/refunds", ['amount' => 1500]) ->assertSessionHasErrors('order'); ``` The boundary deserves its own case: travel exactly 14 days and assert the request is still accepted. Tests at the edge are where off-by-one bugs in `>` versus `>=` show up. ## What the clock does not reach 1. **PHP's native functions.** `time()`, `date()` and `new DateTime()` read the system clock and ignore Carbon's test time. Code that uses them cannot be time-travelled; switch it to `now()`. 2. **The database clock.** A query using `NOW()` or a column default of `CURRENT_TIMESTAMP` is evaluated by the database server, not by PHP. 3. **Queued work in other processes.** A real worker has its own clock; in tests, jobs run in-process or are faked, so this rarely bites. ## Choosing a helper - Use **`travel()`** when the rule is relative to something created in the test ("15 days after delivery"). - Use **`travelTo()`** when the rule depends on a calendar moment, such as a refund policy that changes at midnight on the first of the month. - Use **`freezeTime()`** when the test asserts an exact timestamp, for example a `refunded_at` column, since the value it returns is the one the code will write. - Use the **closure form** when only part of a test should run at another time. ## Related helpers - `Sleep::fake()` stops Laravel's `Sleep` class from actually pausing and can advance Carbon's clock with each fake sleep. - Carbon's own `Carbon::setTestNow()` still works directly, but the test-case helpers read better and reset automatically. ## Interview summary - `travel()->days()`, `travelTo()`, `freezeTime()`, `travelBack()`. - Implemented with `Carbon::setTestNow()`; the clock stays frozen at the chosen moment. - Reset automatically at teardown. - Native PHP time functions and database `NOW()` are outside its reach.