Testing
Learn how to test flows that use OneSDK with mock data.
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 front-end 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:
- You initialize OneSDK in dummy mode.
- OneSDK preloads an an existing individual with personal details and an associated document object of type
PASSPORT
. - You initialize the
ocr
component and call itsstart
method. - OneSDK emits an
input_required
event. - 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. - OneSDK emits a second
input_required
event with statusAWAITING_DOCUMENT_UPLOAD_BACK
. The documentType parameter will be set toDRIVERS_LICENCE
and the side parameter will bet set toback
. - You call the supplied
provideFile
function again with any image. This time theprovideFile
callback will behave as though an invalid image was provided. - OneSDK emits a third
input_required
event with statusAWAITING_DOCUMENT_UPLOAD_INVALID_TYPE
. The other parameters are the same as the previously emitted event. - You call the supplied
provideFile
function again with any image. This time theprovideFile
callback will behave as though a valid image was provided. - 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:
- The preloaded individual has an associated document of type
PASSPORT
, with a single front scan. - The OCR flow will detect a document of type
DRIVERS_LICENCE
- The flow will always start by emitting an
input_required
event - Since the first status is defined as
WAITING_BACK
, a secondinput_required
event will be emitted with this status. - Since the second status is
DOCUMENTS_INVALID
, a thirdinput_required
event will be emitted with this status. - 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.
- The flow will always start by emitting an
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:
- The preloaded individual has an associated document of type
DRIVERS_LICENCE
, with a single front scan but no back scan. - The OCR flow will resume the image capture process:
- The flow will start by emitting an
input_required
event, requesting the back side of the drivers license. The front side was already preloaded. - Since the first remaining status is defined as
DOCUMENTS_INVALID
, a secondinput_required
event will be emitted with this status. - 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.
- The flow will start by emitting an
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
Type name | Description | Required? | Definition |
---|---|---|---|
preloadedIndividual | All details to be “preloaded” for the individual. This means the individual was pre existing in the system. It can also be explicitly set to false to emulate a non pre existing individual. Defaults are shown after this table. | No | false | { individual: PartialIndividualObject documents: PartialDocumentObject[] } |
PartialDocumentObject | Partial description of a document object | Besides the options described next, the scans field may be defined either as an array of PartialScanObject objects, or by the following string shortcuts, which is recommended: "F” for front scan only “both” for both scans (DL only) “none” for no scans When defining ocrResult.status, the value of the scans array is overridden with default scan objects with scan sides defined accordingly. | |
PartialScanObject | Scan object, representing an uploaded image | Defined below | |
ocrFlow | Options regarding the OCR flow | No | |
ocrFlow.detectedType | Fakes the detected type for the uploaded image. | Required if ocrFlow is defined | ```` ```“PASSPORT” | “DRIVERS_LICENCE” ```` |
ocrFlow.statusResults | Define the order in which status results should be faked. | Required if ocrFlow is defined | Array of OCR statuses as defined in the section The OCR Component. Search for OCRStatus |
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.
Updated about 1 month ago