Mateusz Żebrak (a4510cfb) at 29 Mar 09:26
Set the init paramter in the checkerboard table to True
... and 4 more commits
Things done in this MR:
CliveCheckerboardTable
widget created earlier was used on the savings screen.Partly satisfies: #170
Requires: !314 (to check if scrolling is displayed correctly)
Things done in this MR:
CliveCheckerboardTable
widget created earlier was used on the savings screen.Partly satisfies: #170
Requires: !314 (to check if scrolling is displayed correctly)
Not a problem, but wrong usage. This is a lower layer. To deactivate you should use world.commands.deactivate()
Instead of logging current view it would be better to assert_is_screen_active
functions like this require some preconditions so it can proceed, right? This precondition is it has to be on a expected screen? So maybe use assert_is_screen_active
inside functions like go_to_savings, assert_pending_transfers_from_savings_count and maybe more..?
Maybe shorter? we already know they are current pending transfers
so no need to say pending transfers
again;
Something like that?:
Current pending transfers (2)
or
Current pending transfers (amount: 2)
Used like ids (so should be ids) but maybe instead could be used like so instead of 3 classes there will be only 2: interest-info-row-odd
interest-info-row-even
class instead of ID? But maybe instead SavingsBalances
classname can be used
self._title: Static
self._title.update(f"Current pending transfers (number of pending transfers: {len(content.pending_transfers)})")
Mateusz Żebrak (c63fcb85) at 28 Mar 12:22
Use safer DataProvider.is_content_set instead of DataProvider.updat...
Noticed that self.watch(... init=False) is overall bad.
It means we won't ask for some data (even if it might be available) and will receive the next update (so in case of data providers in worst case after next 1.5s + call time)
This MR ensures all self.watch
calls have init=True (default in textual). This requires additional checks if the data is available yet, because it is updated in the background so might be not yet available.
Mateusz Żebrak (5735ded3) at 28 Mar 11:52
Update dynamic thing ASAP (set self.watch init=True and check if da...
... and 1 more commit
public key prefix in testnet is changed to STM so we can use wax in testnet
What's the purpose of this?
Why not create this operation directly via wallet.api.transfer_from_savings
?
Shouldn't also check correct operation was placed in the blockchain? Like other tests
expected what?
expected_operation = prepare_expected_operation(
Why do we need to get that dynamically? Only to prepare expected operations? Aren't we sure, there are no existing operations like that?
The only reason I see is that the replayed blockchain might be extended to have some ongoing operations like that, but I think it's not worth checking that every time in the test and it can be error-prone. Instead when the need arises, just adjust this test when the predefined blockchain gets modified.