# Testing your setup

Finding out that reporting is broken when you need a report is the wrong time to find out.

## The test command

```bash
php artisan larabug:test
```

It builds a test exception and runs it through everything: the environment check, the deduplication window, the filters, the HTTP call, and prints what happened at each step. It exits zero either way, so read its output rather than its exit code.

A matching event should be in your LaraBug application within a few seconds.

## Keeping quiet locally

The default `environments` list is `['production']`, so a local machine reports no exceptions without any further setting. That is usually all you want, and it is also why the test command says the environment is not allowed when you first run it on your laptop. Run it once as `APP_ENV=production php artisan larabug:test` to see the whole path work.

Queue jobs, logs and the other monitors do not check `environments`, so a local install that reports no exceptions can still send those.

## Asserting on reports in your own tests

To check that your code reports an exception without anything leaving the machine, swap the client for the fake:

```php tests/Feature/OrderTest.php
use LaraBug\Facade as LaraBug;

LaraBug::fake();

$this->post('/orders', $payload)->assertStatus(500);

LaraBug::assertSent();
```

Nothing is posted, and the assertion fails if your code swallowed the exception instead of reporting it.

## Do not run the test command in CI

It reports a real event to a real LaraBug application, from a machine that is not where your application runs. Run it once by hand after a deploy to a new environment, and let CI check the things that are actually its business: that the package installs, that `php artisan config:cache` succeeds, and that your own tests pass.