Testing a custom action

Use the following instructions to add unit tests and also test your custom actions in CodeCatalyst workflows.

Adding unit tests

The ADK CLI bootstraps actions with an empty unit test using Jest's testing framework. You can use the empty unit test as a starting point to write sophisticated unit tests. The tests are executed when an action is built, and the action build fails if the tests fail or if the test coverage doesn't meet the expected percentage. You can configure the Jest configuration file (jest.config.js) generated by the ADK CLI to incorporate test coverage and reporting, as well as other forms of testing.

The following JavaScript example uses the Jest testing framework to define a test for an outgoing webhook action:

// @ts-ignore
import * as core from '@aws/codecatalyst/adk-core';
import { expect, test, describe } from '@jest/globals';
import { getHeadersInput } from '../lib/utils/input-util';
import { WEBHOOK_HEADERS_MALFORMED_MESSAGE } from '../lib/constants';

const SAMPLE_INPUT_URL = 'https://hooks.sample.com';
const SAMPLE_INPUT_BODY = '{"Sample": "BODY"}';

describe('Outgoing Webhook Action', () => {
    test('Raises Validation error if webhook headers aren not JSON format', async () => {
        core.getInput = jest.fn().mockImplementation(inputName => {
            switch (inputName) {
                case 'WebhookRequestURL': {
                    return SAMPLE_INPUT_URL;
                }
                case 'WebhookRequestHeaders': {
                    return 'invalidHeaders';
                }
                case 'WebhookRequestBody': {
                    return SAMPLE_INPUT_BODY;
                }
                default: {
                    throw new Error('Unknown input provided');
                }
            }
        });
        expect(() => {
            getHeadersInput();
        }).toThrowError(WEBHOOK_HEADERS_MALFORMED_MESSAGE);
    });
});

Testing actions in workflows

To test your action before publishing as a verified partner, you can run it within the workflow and view the run's details. Your workflow generally runs automatically due to a trigger that can include one or more events, such as a code push or pull request. If a trigger isn't defined in the workflow, the workflow can only be started manually. For more information, see Creating, editing, and deleting a workflow.

The ADK generates a continuous integration (CI) workflow that is ready to be used in CodeCatalyst. By default, a bootstrapped action produces a dist/ folder with an artifact that contains the dependencies the workflow requires to run successfully in CodeCatalyst. You must build the actions locally and push the content of the dist/ folder to the action's source repository before testing the actions in a workflow.

An action is determined by an action identifier, which consists of the action name and action version. In the workflow definition file, this information indicates which action and version to run in the workflow. When an action is not published, . is used as an action identifier in the CI workflow, which is generated by the ADK, while testing. This can help to reference an action that is in the same repository as the workflow file (.codecatalyst/workflows/actionName-CI-Validation.yml).

Name: MyAction-CI-Validation
SchemaVersion: "1.0"
Triggers:
  - Type: PullRequest
    Events: [ open, revision ]
    Branches:
      - feature-.*
Actions:
  ValidateMyAction:
    Identifier: .
    Inputs:
      Sources:
        - WorkflowSource
    Configuration:
      WhoToGreet : 'TEST'
      HowToGreet : 'TEST'

After making any changes to your source code, build your action locally and push your code again to your CodeCatalyst repository before testing the action in a workflow.

To build and push action source code and the bundle

The action can now be tested with the ADK-generated workflow. By default, the workflow's name is ActionName-CI-Validation.