With the HW/FW being more advanced, we need to support different parameters for the integration tests - for example FIPS approved devices need to use different (complex) PINs, sessions need to be opened with specific SCP parameters and similar.
We kept such information in static variables (for example PivTestState.DEFAULT_MANAGEMENT_KEY) which were initialized by a static method (for example PivTestUtils.verifyAndSetup(device)). This approach is not scalable and this PR introduces a TestState class which holds the test related information and is passed into the testing methods.
The class has subclasses for each application (where applicable) which setup and verify the state based on the connected device.
The TestState class holds the following properties:
YubikeyDevice currentDevice - the device which the integration tests is using
ScpParameters scpParameters - SCP related data (keys, kid)
ReconnectDeviceCallback reconnectCallback - callback which will cause a reconnection of a device, provided by the platform (currently Android only) code
boolean isUsbTransport - helper to get the transport flag
The TestState class also provides helper for its sub classes which can be used to open connections and get different sessions.
The subclasses contain specific properties which can be used during a test session. These properties are initialized in the constructor. Currently there are following properties
The platform test framework can execute two types of tests: session specific or device specific. The device specific tests can be used to process information which is not part of the session and also run several session tests during one tests - after each test, the reconnect callback is used to artificially reconnect the device (see OathDeviceTests.changePassword which changes the OATH password in one session and verifies it directly in another).
As part of this PR also the following tests has been updated to use the TestState approach: MultiProtocolReset, PinComplexity and Oath.
To write new integration tests, the only difference is that they should have a second parameter holding the state.
With the HW/FW being more advanced, we need to support different parameters for the integration tests - for example FIPS approved devices need to use different (complex) PINs, sessions need to be opened with specific SCP parameters and similar.
We kept such information in static variables (for example PivTestState.DEFAULT_MANAGEMENT_KEY) which were initialized by a static method (for example PivTestUtils.verifyAndSetup(device)). This approach is not scalable and this PR introduces a TestState class which holds the test related information and is passed into the testing methods.
The class has subclasses for each application (where applicable) which setup and verify the state based on the connected device.
The
TestStateclass holds the following properties:YubikeyDevice currentDevice- the device which the integration tests is usingScpParameters scpParameters- SCP related data (keys, kid)ReconnectDeviceCallback reconnectCallback- callback which will cause a reconnection of a device, provided by the platform (currently Android only) codeboolean isUsbTransport- helper to get the transport flagThe
TestStateclass also provides helper for its sub classes which can be used to open connections and get different sessions.The subclasses contain specific properties which can be used during a test session. These properties are initialized in the constructor. Currently there are following properties
PivTestState:isFipsApproved,defaultPin,defaultPuk,defaultManagementKeyOathTestState:isFipsApproved,passwordOpenPgpTestState:isFipsApproved,defaultUserPin,defaultAdminPinMpeTestState: noneThe platform test framework can execute two types of tests: session specific or device specific. The device specific tests can be used to process information which is not part of the session and also run several session tests during one tests - after each test, the reconnect callback is used to artificially reconnect the device (see
OathDeviceTests.changePasswordwhich changes the OATH password in one session and verifies it directly in another).As part of this PR also the following tests has been updated to use the TestState approach: MultiProtocolReset, PinComplexity and Oath.
To write new integration tests, the only difference is that they should have a second parameter holding the state.