-
Notifications
You must be signed in to change notification settings - Fork 20
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
feat: Add connect command #402
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
7df4b85
Add connect command
Lykhoyda 4940bd1
updates
Lykhoyda 50f4f79
update
Lykhoyda 969b0da
rename
Lykhoyda df05ae6
remove download
Lykhoyda 183732e
remove id
Lykhoyda 7dbfdc2
adjust comment
Lykhoyda 5866028
contain text update
Lykhoyda File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
export const newMultisigPage = { | ||
addressSelector: () => cy.get('[data-cy="input-account-address"]') | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
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.
Personally, I do like the thoroughness of the check of the string but in the past (before your time, maybe even on another FE project!) I recall there was a group consensus that we should just check for the presence of the error element itself but not the text so this is what I've been doing since.
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.
Agreed as long as this container is unique, and only this error would be displayed, in it. In this case, the container is called noAccount.. So we should be fine. Another idea could be that we keep the text check, but only check that it contains "no account found"? So that if we even change the rest, we won't have to change this test?
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.
@asnaith @Tbaut I have mixed feelings about the way of writing e2e tests. If we write the test from the expectation of the user what should happen on the screen, then we indeed carry about the text that will be displayed on the screen. And if we change the text on the UI side the tests would fail which is a valid scenario for me. The way we wrote the current test is we found the element by class and checked for visibility, it's an implementation details test as a user will not deal with the classes or any code at all, the user will see only text. BTW, it's also why I like testing library(https://testing-library.com/docs/) because it interacts only with displayed content by the core principles, and using the main API will not allow you to write such a test.
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.
It's just a matter of how safe we are with what's on the screen, and what maintenance burden this adds. At the end of the day, you and me are the one who will break the tests if we change the text, so we're the one who may be annoyed. The actual best way is to export those strings to shared files, but this is overkill IMHO. Let's keep this string check if you feel strongly about it, I doubt it will be such a maintenance annoyance. And if it it, we can reconsider this practice in the future.
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.
It's not only about checking the strings but keeping in mind the way to write the test, that it should be user-centric. The Cypress default library is super flexible, but from the beginning, it's better to have some guidance and principles for writing the test, and IMO the testing library forces good practices to avoid testing the implementation details. I want that we will all be on the same page. Let me know if you are against testing according to the following principles https://testing-library.com/docs/guiding-principles
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 don't have strong opinions. Also tbh I'm not sure to fully understand the content of the link you posted as it's written in a very abstract way 😄 . I just want our tests to be easy to read/understand, easy to maintain, while obviously being meaningful. I do think it's meaningful whether we check the string or check that this unique component with the error is visible (Cypress is clever enough that if it's present, but not visible, the test will fail). Both have pros/cons. So far in other projects, we didn't check the string because it was easier to maintain and we were 100% sure that if this component is visible, then this message is visible. Now I understand your PoV too, it's safer still to check the string. To go half way, that's why I proposed instead of checking the whole string, to just check the most important part, and the part that will likely not change "No account found". Because if e.g we change the link in the future, I feel it'd be better to not break the test for this.
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.
At least to use "contain.text" is definitely better. The code is updated
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.
@Lykhoyda I'm 100% aligned with you that the cypress tests should be user-centric. Meeting halfway with the "contains" and not an exact match is for sure better than not checking the text at all 👍