Skip to content
This repository has been archived by the owner on Jul 15, 2022. It is now read-only.

headless test plan for firmware updates. add end-to-end test for getLatestFirmwareForDevice #235

Open
gre opened this issue May 4, 2019 · 1 comment

Comments

@gre
Copy link
Contributor

gre commented May 4, 2019

as reminder, this is fundamentally how to do a firmware update:

import getDeviceInfo from '@ledgerhq/live-common/lib/getDeviceInfo'
import manager from '@ledgerhq/live-common/lib/manager'
import prepare from '@ledgerhq/live-common/lib/hw/firmwareUpdate-prepare'
import main from '@ledgerhq/live-common/lib/hw/firmwareUpdate-main'

const deviceInfo = await withDevice('')(t => getDeviceInfo(t))
const firmware = await manager.getLatestFirmwareForDevice(deviceInfo)
if (!firmware) return "up to date"

concat(
  prepare('', firmware),
  main('', firmware)
).subscribe(e => console.log(e))

see that the key part here is getDeviceInfo and getLatestFirmwareForDevice.

For getDeviceInfo, we already have tests on many versions and we've recently seen how it's important to have these tests & all versions covered.

For getLatestFirmwareForDevice, we MUST have a end-to-end test. It involves Manager API calls (so it's mainly the backend team's scope) but it's still good to have this end-to-end test. What's cool is that it just takes deviceInfo parameter, so it would be easy to do the same kind of tests but starting from chosen static deviceInfo object. We must do that on every major firmware version we have.

Now, concerning prepare and main, this is way trickier and not something we can actually test, it's more the scope of firmware team to test this part even tho it would be good to have a way to test this (but since a HSM secured channel is involved here, we can't do without a device).

@gre gre changed the title For each firmware version, add an end-to-end test for getLatestFirmwareForDevice headless test plan for firmware updates. add end-to-end test for getLatestFirmwareForDevice May 4, 2019
@gre
Copy link
Contributor Author

gre commented Jan 18, 2020

in that context, what could be in fact mocked is the whole "socket session", we could have a split on mocking what createSocket is doing and emit mocked observable events.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant