Skip to main content

Calling an action in a test

You can call an action by passing its name or class to callAction():

Testing table actions

To test table actions, you can use a TestAction object with the table() method. This object receives the name of the action you want to test, and replaces the name of the action in any testing method you want to use. For example:

Testing table header actions

To test a header action, you can use the table() method without passing in a specific record to test with:

Testing table bulk actions

To test a bulk action, first call selectTableRecords() and pass in any records you want to select. Then, use the TestAction’s bulk() method to specify the action you want to test. For example:

Testing actions in a schema

If an action belongs to a component in a resource’s infolist, for example, if it is in the belowContent() method of an infolist entry, you can use the TestAction object with the schemaComponent() method. This object receives the name of the action you want to test and replaces the name of the action in any testing method you want to use. For example:

Testing actions inside another action’s schema / form

If an action belongs to a component in another action’s schema() (or form()), for example, if it is in the belowContent() method of a form field in an action modal, you can use the TestAction object with the schemaComponent() method. This object receives the name of the action you want to test and replaces the name of the action in any testing method you want to use. You should pass an array of TestAction objects in order, for example:

Testing resource getFormActions()

For details on how to test custom actions in the getFormActions() of a resource page, refer to the Testing resources documentation.

Testing forms in action modals

To pass an array of data into an action, use the data parameter:
If you ever need to only set an action’s data without immediately calling it, you can use fillForm():

Testing validation errors in an action modal’s form

assertHasNoFormErrors() is used to assert that no validation errors occurred when submitting the action form. To check if a validation error has occurred with the data, use assertHasFormErrors(), similar to assertHasErrors() in Livewire:
To check if an action is pre-filled with data, you can use the assertSchemaStateSet() method:

Testing the content of an action modal

To assert the content of a modal, you should first mount the action (rather than call it which closes the modal). You can then use assertMountedActionModalSee(), assertMountedActionModalDontSee(), assertMountedActionModalSeeHtml() or assertMountedActionModalDontSeeHtml() to assert the modal contains the content that you expect it to:

Testing the existence of an action

To ensure that an action exists or doesn’t, you can use the assertActionExists() or assertActionDoesNotExist() method:
You may pass a function as an additional argument to assert that an action passes a given “truth test”. This is useful for asserting that an action has a specific configuration:

Testing the visibility of an action

To ensure an action is hidden or visible for a user, you can use the assertActionHidden() or assertActionVisible() methods:

Testing disabled actions

To ensure an action is enabled or disabled for a user, you can use the assertActionEnabled() or assertActionDisabled() methods:
To ensure sets of actions exist in the correct order, you can use assertActionListInOrder():
To check if an action is hidden to a user, you can use the assertActionHidden() method:

Testing the label of an action

To ensure an action has the correct label, you can use assertActionHasLabel() and assertActionDoesNotHaveLabel():

Testing the icon of an action

To ensure an action’s button is showing the correct icon, you can use assertActionHasIcon() or assertActionDoesNotHaveIcon():

Testing the color of an action

To ensure that an action’s button is displaying the right color, you can use assertActionHasColor() or assertActionDoesNotHaveColor():

Testing the URL of an action

To ensure an action has the correct URL, you can use assertActionHasUrl(), assertActionDoesNotHaveUrl(), assertActionShouldOpenUrlInNewTab(), and assertActionShouldNotOpenUrlInNewTab():

Testing action arguments

To test action arguments, you can use a TestAction object with the arguments() method. This object receives the name of the action you want to test and replaces the name of the action in any testing method you want to use. For example:

Testing if an action has been halted

To check if an action has been halted, you can use assertActionHalted():

Using action class names in tests

Filament includes a host of prebuilt actions such as CreateAction, EditAction and DeleteAction, and you can use these class names in your tests instead of action names, for example:
If you have your own action classes in your app with a make() method, the name of your action is not discoverable by Filament unless it runs the make() method, which is not efficient. To use your own action class names in your tests, you can add an #[ActionName] attribute to your action class, which Filament can use to discover the name of your action. The name passed to the #[ActionName] attribute should be the same as the name of the action you would normally use in your tests. For example:
Now, you can use the class name in your tests:
If you have an action class that extends the Action class, you can add a getDefaultName() static method to the class, which will be used to discover the name of the action. It also allows users to omit the name of the action from the make() method when instantiating it. For example: