Device emulator

[ashleyfrieze]

JIRA Ticket

None.

Description

While testing device binding journeys using test automation, it's incredibly useful to be able to simulate both device binding and device login.

This change offers a simple client which can be used as an emulator. It provides valid responses to journeys and stores a keypair which can be used, within a test, to mimic a single bound device. It's of no specific use to production scenarios, but helps for testing scenarios where the FR SDK is being used by a test suite.

Discussed with @george-bafaloukas-forgerock - we'd like to offer this as a submission to the OS SDK, which will put it in a useful place for us to use it across various codebases, as well as for other customers to use.

Type of Change

Please Delete options that are not relevant

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

We've used this device emulator code against a Device Binding journey and it works. While there's a way we could simulate the back end and run this against the back end, it would be pretty onerous and wouldn't prove much.

Definition of Done

Check all that apply

• Acceptance criteria is met.
• All tasks listed in the user story have been completed.
• Coded to standards.
• Code peer-reviewed.
• Ensure backward compatibility (special attention).
• API reference docs is updated.
• Unit tests are written.
• Integration tests are written.
• e2e tests are written.
• CI build passing on the feature branch.
• Functional spec is written/updated
• contains example code snippets.
• Change log updated.
• Documentation story is created and tracked.
• UI is completed or ticket is created.
• Demo to PO and team.
• Tech debts and remaining tasks are tracked in separated ticket(s).

Documentation

• Acceptance criteria met
• Spell-check run
• Peer reviewed
• Proofread

[ryanbas21]

Hi @ashleyfrieze thanks for contributing. As this stands we probably wouldn't want to add a testing feature to the sdk in this manner. We try our best to not add dependencies and given this is specifically for testing we would probably want this separated somehow.

This helped add to our thoughts on releasing some sort of package for this purpose (testing related package). For the time being I will leave this open for us to look at and discuss in the coming days hopefully. I just wanted to add something here so you know our thoughts.

Thanks again, and we will definitely reference this as we discuss further this evolution for the SDK

[ashleyfrieze]

@ryanbas21 - thanks for the feedback.