1. Using the Rapid Adapter Builder with Oracle Integration 3
  2. Build an Adapter Using the Rapid Adapter Builder
  3. Build and Test an Adapter
  4. Test an Adapter
  5. Checklist for Testing an Adapter

Checklist for Testing an Adapter

Use the guidelines provided here to create a test plan for your adapter built using the Rapid Adapter Builder.

At a minimum, you must perform the following tests:

Review the Metadata

After pushing an adapter to Oracle Integration, check whether its metadata is accurate and easy to read.

  1. In the navigation pane, click Design, then Adapters.

  2. Find your adapter in the list.

  3. Verify that the following information is correct:

    • Name of the adapter
    • Version

  4. Point to the adapter, and select Open Details Open details icon

  5. Verify that the adapter details are correct and appear as you expect.

    For example:

    • Is all text accurate?
    • Are all links functional, and do they open the correct URLs?
    • Is all text fields a reasonable length?
    • Are there any typos?

  6. Update the metadata as necessary, either now or after you finish testing.

    See Add Info Definitions.

Test Connections

Check whether you can create a connection, whether it meets your requirements, and whether the connection information that is accurate and easy to understand.

  1. Create one or more connections that are based on the adapter.

    Tip:

    To optimize the adapter and reduce the need for documentation and support, partner with a UX writer for this review.

    While creating the connection, verify the following:

    • Are you able to create a connection using your adapter?
    • Does the adapter address all the required scenarios?
    • Do the descriptions of each action make sense?
    • Review all the connection properties and security properties, as well as their corresponding tips.
      • Does the text appear as expected?
      • Does the text make sense?

      • Is the text a reasonable length?

        In general, shorter is better, but being understandable is most important.

      • Is the text consistent?

        For instance, do some fields use verbs while others use nouns?

      • Is terminology consistent and easy to understand?

        For instance, if some fields say Change order while others use Order update, users might get confused.

      • Will the values for any connection or security properties be the same for all connections that developers create using the adapter? If so, set a default value and hide the property in the adapter definition document.

  2. While creating mappings, verify the following:

    • Can you navigate the mapper easily, or is it overwhelming?

    • Are the mappings for the custom response easy to understanding? Are the properties easy to understand?

  3. Create an integration that uses the connection(s).

    See Create an Integration in Using Integrations in Oracle Integration 3.

  4. While testing, if you identified changes that you need to make in the adapter definition document, make the changes either now or after you finish testing.

    See Review a Connection Definition.

Test Integrations

Determine whether the integration runs as expected in runtime.

  1. Test the integration in runtime.

    See Activate an Integration in Using Integrations in Oracle Integration 3.

  2. Verify that the integration runs as expected as well as the following information:

    • Is the response easy to understand?

      For instance, an ideal response returns only the information that users need to know and nothing extra.

    • Did the integration do what it was supposed to do?

      If the integration creates a new record, ensure that the correct information is placed in each field. For example, make sure that the first and last name fields aren't swapped.

  3. If the integration doesn't run as expected, determine why.

    For instance, the API call might have failed.

  4. Update the adapter definition document as necessary, either now or after you finish testing.

    See

Identify Opportunities for Improvement

An adapter that is functional and consistent might still have room for improvement.

For example:

  • Consider a situation where a user must enter the identifier for an object.

    When you test the adapter and enter an identifier, the connection and its integration function as expected. However, in the real world, users can't easily obtain this identifier. For instance, they might know only the display name. Or, you might be able to display only the relevant identifiers in a drop-down.

  • Your adapter might not display custom properties.

    For instance, international companies sometimes have country-specific HR software, each with different required fields for employee records. An adapter that works with only one country's HR software is of limited use. An adapter that works with all of the HR systems, including all of their custom fields, offers a more comprehensive solution.

    Such capabilities aren't part of the adapter definition document that you convert from a Postman collection. Instead, you must update the adapter definition document for these requirements.

The opportunities for improvement can be immense and can lead to scope creep. Work with end users and product owners to identify and prioritize these opportunities for improvement.

Test the Documentation

Before you go live, test the documentation for the adapter against the user interface, and verify the following:

  • Does documentation exist for the adapter?

  • Is the documentation accurate?

  • Are users able to use your documentation to create connections using the adapter?

See Publish the Adapter Documentation.

Complete Additional Testing as Needed

For instance, complete any of the following testing according to your organization's requirements:

  • Functional testing
  • Requirements testing
  • User experience testing
  • Performance testing