Skip to main content

Authenticating as a user

Ensure that you are authenticated to access the app in your TestCase:
Alternatively, if you are using Pest you can use a beforeEach() function at the top of your test file to authenticate:

Testing a resource list page

To test if the list page is able to load, test the list page as a Livewire component, and call assertOk() to ensure that the HTTP response was 200 OK. You can also use the assertCanSeeTableRecords() method to check if records are being displayed in the table:
To test the table on the list page, you should visit the Testing tables section. To test any actions in the header of the page or actions in the table, you should visit the Testing actions section. Below are some common examples of other tests that you can run on the list page. To test that the table search is working, you can use the searchTable() method to search for a specific record. You can also use the assertCanSeeTableRecords() and assertCanNotSeeTableRecords() methods to check if the correct records are being displayed in the table:
To test that the table sorting is working, you can use the sortTable() method to sort the table by a specific column. You can also use the assertCanSeeTableRecords() method to check if the records are being displayed in the correct order:
To test that the table filtering is working, you can use the filterTable() method to filter the table by a specific column. You can also use the assertCanSeeTableRecords() and assertCanNotSeeTableRecords() methods to check if the correct records are being displayed in the table:
To test that the table bulk actions are working, you can use the selectTableRecords() method to select multiple records in the table. You can also use the callAction() method to call a specific action on the selected records:

Testing a resource create page

To test if the create page is able to load, test the create page as a Livewire component, and call assertOk() to ensure that the HTTP response was 200 OK:
To test the form on the create page, you should visit the Testing schemas section. To test any actions in the header of the page or in the form, you should visit the Testing actions section. Below are some common examples of other tests that you can run on the create page. To test that the form is creating records correctly, you can use the fillForm() method to fill in the form fields, and then use the call('create') method to create the record. You can also use the assertNotified() method to check if a notification was displayed, and the assertRedirect() method to check if the user was redirected to another page:
To test that the form is validating properly, you can use the fillForm() method to fill in the form fields, and then use the call('create') method to create the record. You can also use the assertHasFormErrors() method to check if the form has any errors, and the assertNotNotified() method to check if no notification was displayed. You can also use the assertNoRedirect() method to check if the user was not redirected to another page. In this example, we use a Pest dataset to test multiple rules without having to repeat the test code:

Testing a resource edit page

To test if the edit page is able to load, test the edit page as a Livewire component, and call assertOk() to ensure that the HTTP response was 200 OK. You can also use the assertSchemaStateSet() method to check if the form fields are set to the correct values:
To test the form on the edit page, you should visit the Testing schemas section. To test any actions in the header of the page or in the form, you should visit the Testing actions section. Below are some common examples of other tests that you can run on the edit page.
To test that the form is validating properly, you can use the fillForm() method to fill in the form fields, and then use the call('save') method to save the record. You can also use the assertHasFormErrors() method to check if the form has any errors, and the assertNotNotified() method to check if no notification was displayed. In this example, we use a Pest dataset to test multiple rules without having to repeat the test code:
To test that an action is working, such as the DeleteAction, you can use the callAction() method to call the delete action. You can also use the assertNotified() method to check if a notification was displayed, and the assertRedirect() method to check if the user was redirected to another page:

Testing a resource view page

To test if the view page is able to load, test the view page as a Livewire component, and call assertOk() to ensure that the HTTP response was 200 OK. You can also use the assertSchemaStateSet() method to check if the infolist entries are set to the correct values:
To test the infolist on the view page, you should visit the Testing schemas section. To test any actions in the header of the page or in the infolist, you should visit the Testing actions section.

Testing relation managers

To test if a relation manager is rendered on a page, such as the edit page of a resource, you can use the assertSeeLivewire() method to check if the relation manager is being rendered:
Since relation managers are Livewire components, you can also test a relation manager’s functionality itself, like its ability to load successfully with a 200 OK response, with the correct records in the table. When testing a relation manager, you need to pass in the ownerRecord, which is the record from the resource you are inside, and the pageClass, which is the class of the page you are on:
You can test searching, sorting, and filtering in the same way as you would on a resource list page. You can also test actions, for example, the CreateAction in the header of the table:

Testing create / edit page getFormActions()

When testing actions in getFormActions() on a resource page, use the schemaComponent() method targeting the form-actions key in the content schema. For example, if you have a custom Action::make('createAndVerifyEmail') action in the getFormActions() method of your CreateUser page, you can test it like this:

Testing multiple panels

If you have multiple panels and you would like to test a non-default panel, you will need to tell Filament which panel you are testing. This can be done in the setUp() method of the test case, or you can do it at the start of a particular test. Filament usually does this in a middleware when you access the panel through a request, so if you’re not making a request in your test like when testing a Livewire component, you need to set the current panel manually:

Testing multi-tenant panels

When testing resources in multi-tenant panels, you may need to call Filament::bootCurrentPanel() after setting the tenant in order to apply tenant scopes and model event listeners: