Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remaining watch account ui tests #446
Remaining watch account ui tests #446
Changes from 7 commits
784e664
318a655
ed4be59
983b679
0a65852
104e08a
912d8a9
e7f1a52
312cfca
b49a6d7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been searching for a way to achieve the same, in an easier to read way. I've always found aliases pretty convoluted, with the
@
etc.This is nice and generic, but can't we just compare it to what we expect? After all this is all just testing that the pure (and down the file the multisig) address is the same isn't it? It would make this test easier to read and maintain IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I preferred about using the aliases is that when we were inspecting the UI and watching via the pure we were dynamically grabbing and storing whatever data was displayed (without caring, just knowing this is the view when a pure is watched) and then only asserting when we watch via the multisig that the displayed details are the same as what we saw previously.
I've updated now to compare using the static values as requested but this means we are now first asserting on the display when watching a pure key (already covered in other tests) and then again the displayed data when watching a multisig key, a trivial difference that probably makes no change in execution time but it's less of a well-written test in my opinion. We break test writing conventions of only asserting after the point of change (but admittedly we do this all the time especially with
should('be.visible')
checks because we have to 😄).Ultimately if it reads better I guess that matters more but I wanted to explain my view. I still think cypress alias will have their place when checking dynamic data but perhaps it makes less sense when values are static like this (and I do agree the @ syntax is a little odd!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe with my PR using the exact same code, this reads even better, this is how I was thinking about this test originally. Sure it's a bit dumb and we're checking twice the same things (now not repeated, but in a function) but how we arrived at this state is different, and that's what matters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep this reads well, thanks :)