Testing and debugging an action

When it's time to test your application, you can manually execute tests through actions to ensure they deliver the expected outcomes and execute the intended logic. 

You have two methods for testing your action: using the Test run button within your application environment and the GraphQL playground. To verify the behavior of your action, you also have two options: debug logging and the Log message step.

Let's explore how those features work to gain valuable insights for further debugging your application issues. 

Debug logging with Logs

The simplest way to test your action flow is by activating logging within specific action settings. Go to Settings > Logging > Enable logging to turn the feature on. 

Then you can navigate to Logs via the action builder menu. This overview shows all logs belonging to this specific action. 

If you need to view all logged actions, navigate to Tools > Logs.

Here you can find some detailed information about actions performed in your application and their results. Also, Logs enable you to navigate to a specific action or action step that caused an error directly. 

Read more about specific Logs features and their use in Logs and action monitoring.

Test run

Test run allows you to test if your action is processing the query. Depending on whether the action is private or publicly available, you'll have the basic and advanced test features available. Press Test run button in the right corner of your action builder to see your testing options.

Basic and advanced test

When an action is public, you can run your test by typing in the values of to properties available in the action flow. Below, see the example of using the Basic test run for user registration action: 

In the Advanced test run section, you can explore various aspects of an action flow beyond just valid inputs. This is particularly useful if you have numerous fields, as you can store your test data in a separate file and paste it all at once.

It also comes in handy when using custom object input variables. For instance, besides the basic information, the registration process might require additional details about the user's preferences or settings, organized under a 'profile_settings' object:

Playground

If your action is private, the only option you have as a test run is Playground (Betty Blocks GraphiQL). It builds on existing platform features and offers flexible ways of reading, mutating, and managing data, making testing possible by logging in. 

To open the Playground, simply press the Test run > Playground. This screen shows the instructions for configuring the playground to enable the action’s execution.

• Mutation is a piece of code that one has to copy into the playground
• Variables is a configuration of the variables that are needed for the action to run correctly

After following through with authorization, you simply paste the code of the mutation into the top left area (1). Variable configuration needs to be copied into the Variables field in the bottom left area (2).

The action can be run by pressing the Play icon in the center of your screen. The result of the actions will be displayed in the right area of the playground in JSON format.

If the execution of the action is a success, the result will show a JSON structure containing the value of the output variable as configured in the 'Finish' step of your action flow.

In case of failed execution of the action, the result will be shown as an error message in the JSON structure. It can be later used to debug the action.

 

Log message step

After you have tested your action and it doesn’t return the desired results, debugging will be your next step to undertake. Besides the Enable logging feature (explained previously), the Log message action step also allows you to obtain more information about the state of your action at a certain point.

Log message is provided out-of-the-box to log a static text or the contents of a variable to the application logs. 

This step can be used anywhere in your action flow, applied by drag-and-dropping into the desired position. In the Log message options, you can choose the type of message you want to see and add variables you want to log. 

The simple example below shows which variables we'd use to see the error message in Logs each time a user tries to change his email address to the existing one. 

By adding a local variable with a defined filtering rule (Webuser email exists) and using it within the Log message options as a value, we can identify an error in the logs that reveals the email the user attempted to use.

The output of this Log message can be viewed in the application’s logs (navigate to Tools > Logs). 

The main advantage of using Log message instead of enabled logging is that you can precisely tackle problematic areas of your application flows, without receiving multiple messages about each step. Moreover, log results from a Log message stay archived in your application for an unlimited amount of time.