1
0
mirror of https://github.com/trezor/trezor-firmware.git synced 2024-10-20 14:59:06 +00:00
trezor-firmware/tests
JoeGruff e3ea32a986 multi: Add decred staking.
Add two new input and four output script types.

Decred ticket purchases consist of a stake submission, op returns, and
change addresses. Although change addresses are allowed by consensus,
they are no longer used in practice and so have been given the
restrictions of a null pubkey and no value. Stake scripts are almost
identical to p2pkh or p2sh except for an extra opcode in front. Inputs
are currently only used in the form of one input three outputs with the
first output, or stake submission, paying to a public key hash, or with
two inputs and five outputs with the stake submission paying to a
multisig script hash. The op returns are directed to the user in the
case of one and the voting service provider and user in the case of two.

One of the sstx commitment for a ticket must pay back to the trezor
wallet. This is checked and an error is thrown if we don't find the
expected public key hash.

Because this adds the ability to create new types of outputs once the
ticket votes, two new input script types are also needed. A successful
vote will lead to a stake generation script that must be spent, and an
unsuccessful vote will lead to a revocation script that must be spent.
If we allowed stake change scripts to have a valid pubkey, that too
would require another op code, but we disallow those for output.
2021-03-17 12:16:08 +01:00
..
burn_tests
click_tests feat(core): hold homescreen to lock 2021-02-24 00:10:10 +01:00
device_tests multi: Add decred staking. 2021-03-17 12:16:08 +01:00
emulators
fido_tests ci: enable editorconfig checks, fix whitespace issues 2020-11-11 14:43:50 +01:00
persistence_tests tests: use modified protobuf classes correctly 2021-02-10 10:56:52 +01:00
txcache multi: Add decred staking. 2021-03-17 12:16:08 +01:00
ui_tests multi: Add decred staking. 2021-03-17 12:16:08 +01:00
upgrade_tests style: apply black 20.8b1 2020-09-29 11:30:40 +02:00
__init__.py
.gitignore
bip32.py feat!(python): drop Mapping protocol support from MessageType 2020-10-30 10:25:51 +01:00
buttons.py
common.py feat(tests): use JSON descriptions in test identifiers 2021-01-21 15:26:04 +01:00
conftest.py feat(tests): dump UI test report as you go 2021-01-11 16:47:59 +01:00
device_handler.py
download_emulators.sh tests: replace emulators URL 2020-08-27 20:01:23 +02:00
emulators.py style: apply black 20.8b1 2020-09-29 11:30:40 +02:00
README.md
REGISTERED_MARKERS
tx_cache.py

Tests

Burn tests

These tests are doing a simple read/write operations on the device to see if the hardware can endure high number of flash writes. Meant to be run on the device directly for a long period of time.

Device tests

Device tests are integration tests that can be run against either emulator or on an actual device. You are responsible to provide either an emulator or a device with Debug mode present.

Device tests

The original version of device tests. These tests can be run against both Model One and Model T.

See device-tests.md for instructions how to run it.

UI tests

UI tests use device tests and take screenshots of every screen change and compare them against fixtures. Currently for model T only.

See ui-tests.md for more info.

Click tests

Click tests are a next-generation of the Device tests. The tests are quite similar, but they are capable of imitating user's interaction with the screen.

Fido tests

Implement U2F/FIDO2 tests.

Upgrade tests

These tests test upgrade from one firmware version to another. They initialize an emulator on some specific version and then pass its storage to another version to see if the firmware operates as expected. They use fixtures from https://firmware.corp.sldev.cz/upgrade_tests/ which can be downloaded using the download_emulators.sh script.

See the upgrade-tests.md for instructions how to run it.

Persistence tests

These tests test the Persistence mode, which is currently used in the device recovery. These tests launch the emulator themselves and they are capable of restarting or stopping it simulating user's plugging in or plugging out the device.