Authenticating as a user
Ensure that you are authenticated to access the app in yourTestCase:
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 callassertOk() 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:
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:
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:
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:
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 callassertOk() to ensure that the HTTP response was 200 OK:
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:
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 callassertOk() 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:
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:
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 callassertOk() 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:
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 theassertSeeLivewire() method to check if the relation manager is being rendered:
ownerRecord, which is the record from the resource you are inside, and the pageClass, which is the class of the page you are on:
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 thesetUp() 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 callFilament::bootCurrentPanel() after setting the tenant in order to apply tenant scopes and model event listeners: