|
| 1 | +## Pest |
| 2 | + |
| 3 | +### Testing |
| 4 | +- If you need to verify a feature is working, write or update a Unit / Feature test. |
| 5 | + |
| 6 | +### Pest Tests |
| 7 | +- All tests must be written using Pest. Use `php artisan make:test --pest <name>`. |
| 8 | +- You must not remove any tests or test files from the tests directory without approval. These are not temporary or helper files - these are core to the application. |
| 9 | +- Tests should test all of the happy paths, failure paths, and weird paths. |
| 10 | +- Tests live in the `tests/Feature` and `tests/Unit` directories. |
| 11 | +- Pest tests look and behave like this: |
| 12 | +<code-snippet name="Basic Pest Test Example" lang="php"> |
| 13 | +it('is true', function () { |
| 14 | + expect(true)->toBeTrue(); |
| 15 | +}); |
| 16 | +</code-snippet> |
| 17 | + |
| 18 | +### Running Tests |
| 19 | + |
| 20 | +After you have made all changes to the code, be sure to perform the following steps in the order shown: |
| 21 | + |
| 22 | +1. Delete the file `vendor/orchestra/testbench-core/laravel/storage/logs/laravel.log`. |
| 23 | +2. Run the console command `php vendor/bin/pest`. |
| 24 | +3. Run the console command `composer style:snippets`. |
| 25 | +4. Run the console command `composer reset:snippets`. |
| 26 | + |
| 27 | +If the tests fail, carefully review the output log as well as the contents of the created file `vendor/orchestra/testbench-core/laravel/storage/logs/laravel.log`. |
| 28 | + |
| 29 | +Once you understand the problem, fix it. |
| 30 | +- Run the minimal number of tests using an appropriate filter before finalizing code edits. |
| 31 | +- To run all tests: `php vendor/bin/pest`. |
| 32 | +- To run all tests in a file: `php vendor/bin/pest tests/Feature/ExampleTest.php`. |
| 33 | +- To filter on a particular test name: `php vendor/bin/pest --filter=testName` (recommended after making a change to a related file). |
| 34 | +- When the tests relating to your changes are passing, ask the user if they would like to run the entire test suite to ensure everything is still passing. |
| 35 | + |
| 36 | +### Pest Assertions |
| 37 | +- When asserting status codes on a response, use the specific method like `assertForbidden` and `assertNotFound` instead of using `assertStatus(403)` or similar, e.g.: |
| 38 | +<code-snippet name="Pest Example Asserting postJson Response" lang="php"> |
| 39 | +it('returns all', function () { |
| 40 | + $response = $this->postJson('/api/docs', []); |
| 41 | + |
| 42 | + $response->assertSuccessful(); |
| 43 | +}); |
| 44 | +</code-snippet> |
| 45 | + |
| 46 | +### Mocking |
| 47 | +- Mocking can be very helpful when appropriate. |
| 48 | +- When mocking, you can use the `Pest\Laravel\mock` Pest function, but always import it via `use function Pest\Laravel\mock;` before using it. Alternatively, you can use `$this->mock()` if existing tests do. |
| 49 | +- You can also create partial mocks using the same import or self method. |
| 50 | + |
| 51 | +### Datasets |
| 52 | +- Use datasets in Pest to simplify tests which have a lot of duplicated data. This is often the case when testing validation rules, so consider going with this solution when writing tests for validation rules. |
| 53 | + |
| 54 | +<code-snippet name="Pest Dataset Example" lang="php"> |
| 55 | +it('has emails', function (string $email) { |
| 56 | + expect($email)->not->toBeEmpty(); |
| 57 | +})->with([ |
| 58 | + |
| 59 | + |
| 60 | +]); |
| 61 | +</code-snippet> |
0 commit comments