-
-
Notifications
You must be signed in to change notification settings - Fork 829
Reduce height of toggle on expanded view source event #9067
Conversation
Signed-off-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Signed-off-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
"created and configured the room."); | ||
|
||
// Edit message | ||
cy.get(".mx_RoomView_body .mx_EventTile").contains(".mx_EventTile_line", "Message").within(() => { |
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.
If there can be multiple items (like I would expect for tiles) I suggest to always use contains
instead of get
.
Otherwise Cypress runs the contains test on the first result of cy.get(".mx_RoomView_body .mx_EventTile")
.
cy.get(".mx_RoomView_body .mx_EventTile").contains(".mx_EventTile_line", "Message").within(() => { | |
cy.contains(".mx_RoomView_body .mx_EventTile .mx_EventTile_line", "Message").within(() => { |
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 was following other existing examples on threads.spec.ts
without knowing what I was doing.
Thanks for the info!
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 was following other existing examples on
threads.spec.ts
.Thanks for the info!
Most of the time you are lucky that only a single element matches.
But imho the tests are more reliable when using cy.contains
.
@@ -143,6 +143,37 @@ describe("Timeline", () => { | |||
}); | |||
}); | |||
|
|||
it("should set size and position to event toggle on expanded view source event", () => { |
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 wonder if we can re-organise the tests to have one test that goes through all the event source bits. In this particular place I am thinking of merging it with https://github.com/matrix-org/matrix-react-sdk/blob/develop/cypress/e2e/14-timeline/timeline.spec.ts#L154
While it is nice to separate every case it may take too long in the future when we are adding more and more tests.
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.
Probably I just don't know what I am doing (ie. ignorance), but I saw this part of the docs: https://github.com/matrix-org/matrix-react-sdk/blob/develop/docs/cypress.md#good-test-hygiene
- Test a well-isolated unit of functionality. The more specific, the easier it will be to tell what's wrong when they fail.
- Don't depend on state from other tests: any given test should be able to run in isolation.
Is it fine to merge several tests into one, if the same function is tested?
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.
Probably I just don't know what I am doing (ie. ignorance), but I saw this part of the docs: https://github.com/matrix-org/matrix-react-sdk/blob/develop/docs/cypress.md#good-test-hygiene
Good point. Sorry for confusing you. Going to discuss that part of the docs.
Is it fine to merge several tests into one, if the same function is tested?
I would say yes as long as it tests the same bits and it shares the steps getting there. Here it is all about the event source view. On the other hand I would not mix up „sign up“ and „event source view“ tests for example.
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 would say yes as long as it tests the same bits and it shares the steps getting there. Here it is all about the event source view. On the other hand I would not mix up „sign up“ and „event source view“ tests for example.
That totally makes sense. It would be perfect if the policy would be available as documentation.
Signed-off-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Signed-off-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Closes element-hq/element-web#22873
This PR reduces height of clickable toggle area on expanded view source event.
Signed-off-by: Suguru Hirahara luixxiul@users.noreply.github.com
type: defect
Checklist
Here's what your changelog entry will look like:
🐛 Bug Fixes