Testing OneSDK

In order to facilitate quick prototyping and client testing, OneSDK provides a "dummy" mode, which uses mock data. This allows you to:

• Build out your frontend experience quicker by removing dependencies on backend systems.
• Automate testing client-side happy paths and error cases with isolated and repeatable processes.

When in dummy mode, OneSDK will use mocked data to facilitate client-side testing. All mocked requests and their corresponding responses are logged in the browser's console.

You can also customize the mocked data in order to test specific flows through your codebase.

Initializing OneSDK in dummy mode

The following example initializes OneSDK in dummy mode. Note that you do not need to provide a session object.

const configuration = {
  mode: 'dummy',
};

const oneSdk = await OneSdk(configuration);

This is all you need to do to use OneSDK components with mocked data. The specific

You can see the mocked network traffic by configuring your browser to display all logs (verbose logging).

Understanding the default mocked OCR flow

If you don't customize the mocked flow, OneSDK will behave as follows:

1. You initialize OneSDK in dummy mode.
2. OneSDK preloads an an existing individual with personal details and an associated document object of type PASSPORT.
3. You initialize the ocr component and call its start method.
4. OneSDK emits an input_required event.
5. In your event listener you call the supplied provideFile function with any image. The function will behave as though you provided an image of a drivers license.
6. OneSDK emits a second input_required event with status AWAITING_DOCUMENT_UPLOAD_BACK. The documentType parameter will be set to DRIVERS_LICENCE and the side parameter will bet set to back.
7. You call the supplied provideFile function again with any image. This time the provideFile callback will behave as though an invalid image was provided.
8. OneSDK emits a third input_required event with status AWAITING_DOCUMENT_UPLOAD_INVALID_TYPE. The other parameters are the same as the previously emitted event.
9. You call the supplied provideFile function again with any image. This time the provideFile callback will behave as though a valid image was provided.
10. OneSDK emits a results event with the final document object.

For each of these submissions, the document object returned is defined with the same default values described below, except by the scans array, which will vary according to the returned result status.

Customizing the mocked OCR flow

You can define your own mocked OCR flows instead of using the default one. When initializing OneSDK, specify an object as the mode instead of the string dummy.

You can define the individual's details that are preloaded, as well as the type of document detected by OCR and the status of each image capture step.

The default mock configuration

The following example specifies a flow that is equivalent to the default one:

const mockedIndividual = {}
const mockedDocument = {}

const config = {
  mode: {
    modeName: 'dummy',
    mocks: {
      preloadedIndividual: {
        documents: [{ idType: "PASSPORT", scans: "F" }],
      },
      ocrFlow: {
        detectedType: "DRIVERS_LICENCE",
        statusResults: [OCRStatus.WAITING_BACK, OCRStatus.DOCUMENTS_INVALID, OCRStatus.COMPLETE],
      }
    }
  }
}
const oneSdk = await OneSdk(config)

This configuration works as follows:

1. The preloaded individual has an associated document of type PASSPORT, with a single front scan.
2. The OCR flow will detect a document of type DRIVERS_LICENCE
   1. The flow will always start by emitting an input_required event
   2. Since the first status is defined as WAITING_BACK, a second input_required event will be emitted with this status.
   3. Since the second status is DOCUMENTS_INVALID, a third input_required event will be emitted with this status.
   4. Since the final status is COMPLETE, a results event will be emitted with the final document object. The final document object will contain all the document defaults and two scans also containing the default data.

Preloading a document that has already been captured via OCR

An end user may complete the OCR process, exit the app, and return to the app later to complete their onboarding journey. You can test this scenario by configuring OneSDK to preload a document that has already been captured via OCR.

For this scenario, you don't need to define the ocrFlow property. Instead you define the ocrResult property on the document that is preloaded. The document scans will be populated automatically.

const config = {
  mode: {
    modeName: 'dummy',
    mocks: {
      preloadedIndividual: {
        documents: [{ idType: "PASSPORT", ocrResult: { status: OCRStatus.COMPLETE } }],
      },
    },
  },
}

const oneSdk = await OneSdk(config)

The OCR component will immediately emit the results event with the document. No input_required events will be emitted.

Preloading a document that is partially captured via OCR

An end user may start the OCR process, exit the app, and return to the app later to complete capturing their identity document. You can test this scenario by configuring OneSDK to preload a document that has been captured partially via OCR, as well as the remaining steps that need to to be performed.

For this scenario, you need to define both the ocrResult property on the document that is preloaded with the status previously reached by the user, and the ocrFlow property with the remaining statuses ending in COMPLETE.

const config = {
  mode: {
    modeName: 'dummy',
    mocks: {
      preloadedIndividual: {
        documents: [{ idType: "DRIVERS_LICENCE", ocrResult: { status: OCRStatus.WAITING_BACK } }],
      },
      ocrFlow: {
        detectedType: "DRIVERS_LICENCE",
        statusResults: [OCRStatus.DOCUMENTS_INVALID, OCRStatus.COMPLETE],
      }
    }
  }
}

const oneSdk = await OneSdk(config)

This configuration works as follows:

1. The preloaded individual has an associated document of type DRIVERS_LICENCE, with a single front scan but no back scan.
2. The OCR flow will resume the image capture process:
   1. The flow will start by emitting an input_required event, requesting the back side of the drivers license. The front side was already preloaded.
   2. Since the first remaining status is defined as DOCUMENTS_INVALID, a second input_required event will be emitted with this status.
   3. Since the final remaining status is COMPLETE, a results event will be emitted with the final document object. The final document object will contain all the document defaults and two scans also containing the default data.

Preloading a document where OCR capture was interrupted

For various reasons the OCR process may be interrupted before any scans could be captured.

Implementing this scenario is similar to implementing the partial capture scenario. However the preloaded status is WAITING_OCR_RUN and the first remaining status is WAITING_FRONT.

const config = {
  mode: {
    modeName: 'dummy',
    mocks: {
      preloadedIndividual: {
        documents: [{ idType: "DRIVERS_LICENCE", ocrResult: { status: OCRStatus.WAITING_OCR_RUN } }],
      },
      ocrFlow: {
        detectedType: "DRIVERS_LICENCE",
        statusResults: [OCRStatus.WAITING_FRONT, OCRStatus.WAITING_BACK, OCRStatus.COMPLETE],
      }
    }
  }
}

const oneSdk = await OneSdk(config)

Preloading an individual with customized personal information

You can also define the personal information different to the default mocked data.

The following example defines a preloaded individual with a passport document already captured via OCR, where the name is "Jack Davis".

const config = {
  mode: {
    modeName: 'dummy',
    mocks: {
      preloadedIndividual: {
        individual: { name: { givenName: "Jack", familyName: "Davis" }},
        documents: [{ idType: "PASSPORT", ocrResult: { status: OCRStatus.COMPLETE } }]
      }
    }
  }
}

const oneSdk = await OneSdk(config)

Detailed schema

PartialIndividualObject is any subset of the following object, which will be deep merged with your provided values:

{
    "entityId": "mockpreloaded-{randomUUID}",
    "customerReference": "dummy-session",
    "name": {
        "givenName": "John",
        "middleName": null,
        "familyName": "Doe",
        "displayName": null
    },
    "dateOfBirth": "1991-10-16",
    "gender": null,
    "extraData": {},
    "phoneNumber": ...,
    // addresses require specific object format, not described in this document
    "addresses": [], 
    ...
}

PartialDocumentObject is any subset of the following object, which will be deep merged with your provided values:

{
    "idType": "OTHER",
    "documentId": "mockpreloaded-{randomUUID}",
    "ocrResult": {}
    "idNumber": "{random}",
    "idSubType": null,
    "scans": [],
    "verified": {
        "electronic": null,
        "manual": null
    },
    "dateOfBirth": null,
    "region": null,
    "country": "AUS",
    "gender": null,
    "extraData": {
      ...
    },
    "idExpiry": null,
    ...
}

PartialScanObject is any subset of the following object

{
      "scanId": "{randomUUID}",
      "fileUploadUuid": null,
      "file": null,
      "mimeType": "image/jpeg",
      "side": "F" | "B",
      "scanCreated": "2022-08-25T03:28:54.000Z", // ISO 8601 GMT timestamp
      "scanName": "dl-front.jpg | dl-back.jpg" // assigned automatically according to "side"
  }

🚧

The description above is incomplete and should be used for prototyping purposes only. Do not take it as a description of our API.