Test Action Chains

You can use the Tests editor–located on the Action Chain editor's Tests tab–to implement a test-driven development approach to designing, creating, and maintaining your action chains, or to implement your own methodology. Using the Tests editor, you can easily define test cases for an action chain and run them at any time, to ensure that code changes haven’t broken any functionality.

The Tests editor removes the need to manually code a test for each code path by:

• Displaying the action chain’s input parameters, context variables and context constants, so that you just need to enter their values for the test.
• Displaying the actions that need their results provided for them, for you to provide the results for the code path being tested. For Call R actions, functionality is available for you to quickly get and copy their responses.
• Suggesting expectations for the test, based on the provided values.

When testing action chains, the first thing you should do is figure out all of the possible code paths, since each one is a scenario that needs to be tested to achieve full test coverage. More complex code paths, however, might have more than one scenario that should be tested.

After identifying the code paths, you create at least one test for each, depending on how many scenarios there are for a path. For each test, you need to:

• Provide any initial values, such as initial values for variables and input parameters, that are needed to execute the code in the code path being tested. For instance, this code needs the value of the $page.variables.userEnteredString variable to execute. The variable is used to count the number of characters that a user entered into an Input Text component that's bound to the variable. Since the variable's value is needed to run the code, you need to provide a value for it that is appropriate for the test case being tested.
  
  
  Description of the illustration jsac-test-var-used.png
  
  
• For each action that can't automatically return a value during testing, due to limitations, you need to provide the action's return value for the code path being tested, as a mock. Actions that need their results provided for them are shown in the Mocks section.

  In this example, a new employee record is added using a Call REST action, which can't automatically return a value during testing. A return value must be provided for the Call REST action, which would be the action's result after adding the new record:
  
  Description of the illustration jsac-tests-call-rest-mock.png
  

• Once you've provided the values for the test case, expectations are automatically generated for you, based on those values. Select the expected results, such as a variable's final value, to test against.

  For instance, after you provide the initial values and mocks for a test, if VB Studio detects that a variable's final value will be 5, this expectation will be suggested to you. You can then add the expectation to the test, to test against. For the test to pass, all expectations have to be met.

The goal is to fully test your action chain by testing each of its code paths. If your tests cover the expected results for each code path, the value for Coverage will be 100%.

In the example below, three tests have been created for the three code paths that need to be covered to achieve full test coverage: Addition Test, Invalid Operator Test, and the Subtraction Test. Therefore, the value for Coverage is 100%, as you can see in the upper left corner of the editor.

The Addition Test, which tests the if operator_ip === '+' code block, is shown in the Properties pane. In the Parameters section, the three input parameter values that were entered to execute the addition block of code are shown, and the Expectations section shows the expected results:

Description of the illustration jsac-testing-action-chain-example.jpg

The source code for all of your tests is stored in a separate JSON file, actionchainname-tests.json, for easier maintenance. To view this file's contents, click JSON in the left pane. You can also find this file under the artifact's chains folder in the Navigator's Source View tab.

Description of the illustration jsac-tests-json.png

Create a Test for a Test Case

The first time you access the Tests editor, click the + Test button to create a test for a particular test case. The test name defaults to Test 1; enter a more descriptive name for the test case, if you want.

To create a test for a test case:

1. In the Context section, provide the initial values for any context variables and constants that are used in the code path that is being tested. For instance, if a variable is used in the code path for a calculation, you'll need to provide a value for the variable that appropriately tests the code path.

   Note:

   If a variable or a constant's value is set by the code being tested and not required to execute the code, you don't provide an initial value for it. The expected value for the variable or constant will be suggested to you as an expectation. For instance, in the example that follows, the value for the variable $page.variables.Answer in set by the Assign Variable action. Since the value is set by code, the expected value for the variable is suggested to you in the Expectations section, as an expectation.
2. In the Parameters section, provide the values for any input parameters that are used in the code path. In this example, values have been entered for the three input parameters that are used in the addition code path:
   
   
   Description of the illustration jsac-test-input-values-example.png
   
   
3. In the Mocks section, which shows actions that need their results provided for them, provide the results for any listed actions, and ensure that the values are appropriate for the test case. For instance, if a Call REST action is used, you'll need to provide a response from the Call REST action that properly tests the code for the particular test case.
   
   
   Description of the illustration jsac-testing-mocks.jpg
   
   

   These actions always require mocked results:

   • Call Component
   • Call REST
   • Call Variable
   • Get Location
   • Scan Barcode

   To provide a mock for an action, click the action in the Mocks section. In the resulting window, provide a value that is appropriate for the test case.

   If you need to mock a Call REST action, click the Make a REST request to get result data for this mock link to copy a response from a REST request to paste into the Body field:
   
   Description of the illustration jsac-mocks-popup.jpg
   

   You will be taken to the Endpoint tab for the Call REST action. Here, you can modify the request to get and copy the response required to mock the action’s result:
   
   Description of the illustration jsac-get-call-rest-return-example.jpg
   

   Shown here are the copied responses from the Call REST action requests, provided as mocks:
   
   Description of the illustration jsac-example-call-rest-results.png
   

   To add a mocked result for an action that isn’t shown in the Mocks section, click the Add icon (+) for the Mocks section. Select the action from the Action drop-down list, then provide the value for the test case in the Return field.

4. Now that you've provided the values for the test case, you can get suggested expectations based on those values by clicking the Get Suggestions button in the Expectations section.

   Shown here are the suggested expectations that are based on the values entered for the Addition Test. In the Expectations section, use the Add All or Add links to add the applicable expectations. To refresh the expectations list, click Refresh:
   
   Description of the illustration jsac-expectations-based-values.jpg
   

   To add your own expectation, click the Add icon (+) for the Expectations section. Select whether you’d like to create an expectation for an action’s parameter, an action’s return value, a context variable, or the action chain’s return value:
   
   Description of the illustration jsac-expectations-box.png
   

   Make the appropriate selections for the expectation and provide the expected value, as shown in this example. Click OK:
   
   Description of the illustration jsac-expectations-box-example.png
   

Run the Tests

Once you've defined the tests, you can run them individually or all at once using the Run or Run All button.

After running the tests, a green icon beside a test indicates that its expectations were as expected and a red icon indicates an unexpected result. The reason for the failure is shown in the Expectations section.

If you incorrectly set an expected value and the detected expected value is correct, click the Accept as expected value link to change the expected value to the detected value:

Description of the illustration jsac-test-failed.jpg

Use the Tests Footer in Your App UI

When you define multiple tests for each action chain in an App UI, it might be easier to manage tests at the App UI level. You can do this using the Tests footer at the bottom of your browser.

Description of the illustration test-action-chain-aggregate-appui.png

This aggregate view helps you get a quick look at the status of all action chain tests in an App UI. When tests fail, you can use this view to quickly access the editor for each failed test and take action as needed.

While you can also run all tests in your App UI from here, it isn't really required if you've already triggered them. Action chain tests run in the background, even when you're not actively working on your App UI, and the results are saved. So if you are working on an App UI, only tests impacted by your changes (for example, if you added a new variable or updated an existing function) are scheduled to run again. You'll likely see something similar to this image until VB Studio actually runs those tests for you (after 10 seconds of inactivity):

Description of the illustration tests-interim-vbs.png

This way, your test results are always available and up-to-date, and you can rely on them to identify and fix code-breaking changes.