Android Testing Framework

The Zendrive SDK testing framework allows developers to perform 'at-desk' integration testing for a variety of use cases and end-user scenarios. These include simulations for trip lifecycle, automatic trip detection, driving behavior events, and collisions.

Developers can test the customer application's UI components by receiving callbacks for a simulated trip without physically going for a drive. The testing workflow can then be rolled into a continuous integration (CI) pipeline.

This page outlines step-by-step instructions to integrate the Zendrive Android Testing SDK into your application.

Release Updates for ZendriveSDK-testing

v.9.1.0

There are no ZendriveSDK-testing updates for Android 13 in this release.

v9.0.0

There are no ZendriveSDK-testing updates for Android 13 in this release.

v8.3.0

New Features

• Added a field for Direction Of Impact in the accidentInfo class.

• Removed the list of tags in ZendriveTagInfo and added ZendriveVehicleTaggingDetails in MockDrive.

v8.2.0

Improvements / Bug Fixes

• Added collision severity and vehicle type fields to accidentInfo class.

• Integrated the Zendrive testing library.

v8.0.0

New Features

Trip extrapolation.

• Customers are to add ZendriveVehicleTaggingDetails to their gradle files.

• Add the ZendriveSDK-testing and ZendriveSDKdependencies to your module’s build.gradle file.

build.gradle

//Existing Zendrive library dependency
implementation 'com.zendrive.sdk.android:ZendriveSDK:10.0.3'

// Add the below testing dependency 
implementation 'com.zendrive.sdk.android:ZendriveSDK-testing:10.0.3' 

The testing framework must not be shipped with the production application. We recommend that developers create a new target which uses the SDK testing library. See Tips and Best Practices below.

Enable Testing Framework

1. Ensure that Zendrive SDK is enabled.

2. The testing framework only works when the trip detection mode is automatic. Hence, when initializing the SDK, set ZendriveDriveDetectionMode to AUTO_ON.

Usage

Once the testing framework is enabled, developers can simulate the trip lifecycle. Developers can choose from a preset trip or create a custom trip. Once a simulation is triggered, the application will receive the configured callbacks automatically. Developers can also simulate the trip when the test application is in background.

Selecting Preset Trips

Zendrive recommends that developers simulate from a list of preset trips. Each preset trip has an in-built trip lifecycle with a selection of events. Choose from the following list of preset trip types:

Preset Trip Type	Distance	Duration	Events
Preset Trip Type	Distance	Duration	Events
URBAN_10_MIN	4445 meters	10 minutes	Hard brake, Aggressive acceleration
HIGHWAY_60_MIN	59112 meters	58 minutes	Hard brake, Overspeeding, Phone handling
URBAN_30_MIN_COLLISION	50130 meters	31 minutes	Hard brake, Collision, Hard Turn

The sample code illustrates how to build a ZendriveMockDrive object for a preset URBAN_10_MIN.

// Build a MockDrive instance using one of the provided PresetTripType.
MockDrive.Builder mockDriveBuilder = MockDrive.Builder.presetMockDrive(context, PresetTripType.URBAN_10_MIN);

// Build to create the MockDrive instance.
MockDrive mockDrive = mockDriveBuilder.build();

The user can also modify a preset trip with application-specific use cases and then simulate a trip. This is useful when developers wish to modify trip distance or duration and add or remove events.

Running the Simulation

Before running the simulation, the application should subclass the ZendriveBroadcastReceiver and implement the abstract handlers for SDK callbacks.

Once you have the MockDrive object, you can invoke the simulate method.

A configured trip might be very long. To complete testing within a shorter time frame, the simulation time must be specified in seconds.

MockZendriveOperationResult result = mockDrive.simulate(context, runTimeInSecs);    
if (!result.isSuccess()) {
    Log.e(result.getErrorCode().name(), result.getErrorMessage());
}    

The application will then receive the onDriveStart, onDriveEnd, onDriveAnalysed and onAccident callbacks at configured times.

Defining Custom Trips (Optional)

If developers need fine-grain control over mock-trip definitions, the testing library provides a MockDrive.Builder which can be used to set all trip parameters, as follows:

MockDrive.Builder mockDriveBuilder = MockDrive.Builder.newAutoDrive(driveStartTimestamp, driveEndTimestamp)
    .setAverageSpeed(driveAverageSpeed)
    .setMaxSpeed(driveMaxSpeed)
    .setDistanceMeters(driveDistance)
    .setScore(zendriveDriveScore)
    .setDriveType(zendriveDriveType)
    .setUserMode(zendriveUserMode)
    .setWayPoints(driveWaypointList);

// Set the delays of the callbacks sent via ZendriveBroadcastReceiver if needed.
mockDriveBuilder.setOnDriveStartDelay(onDriveStartCallbackDelay)
        .setOnDriveEndDelay(onDriveEndCallbackDelay)
        .setOnDriveAnalyzedDelay(onDriveAnalyzedCallbackDelay);

// Construct and add MockEventBuilder to the builder.
mockDriveBuilder.addEventBuilder(mockEventBuilder);

// Build to create the MockDrive instance.
MockDrive mockDrive = mockDriveBuilder.build();           

Supported SDK APIs

The testing library is designed to support a selection of APIs for test purposes.

Supported APIs

The following supported APIs can be used for testing purposes:

• setup

• isSDKSetup

• getActiveDriveInfo

• getZendriveSettings

• getZendriveState

• setZendriveDriveDetectionMode

• startSession

• stopSession

• teardown

• wipeOut

• getBuildVersion

• getEventSupportForDevice

• isAccidentDetectionSupported

• isValidInputParameter

• ZendriveFeedback.addDriveCategory

• ZendriveFeedback.addEventOccurrence

Unsupported APIs

Unsupported APIs either return errors or return default values.

The following APIs return the error code UNSUPPORTED_OPERATION in the operation result:

• startDrive

• stopManualDrive

• triggerMockAccident

• uploadAllDebugDataAndLogs

• ZendriveInsurance.startDriveWithPeriod1

• ZendriveInsurance.startDriveWithPeriod2

• ZendriveInsurance.startDriveWithPeriod3

• ZendriveInsurance.stopPeriod

• ZendriveInsurance.startPeriod1 (deprecated)

• ZendriveDebug.uploadAllZendriveData

The following APIs will return the default values:

• getZendriveSettings: This returns empty lists of ZendriveSettingErrors and ZendriveSettingWarnings

Tips and Best Practices

The testing framework must not be shipped with the production application. We recommend that developers create a new target which uses the SDK testing library. To create a new testing variant, include the following code in your module’s build.gradle file

android {
    ...
    productFlavors {
        ...
        zendrivesdktest {
            ...
        }
         ...
    }
    ...
}      

While the testing framework removes the necessity to go for a physical drive, we still recommend that you go for a drive to test the application. The following features of Zendrive SDK cannot be tested using this library. We plan to include these in future releases of the testing framework:

• onDriveResume, onZendriveSettingsConfigChanged callbacks.

• Manual trip lifecycle.

• ZendriveInsurance and ZendriveFeedback APIs.