docs: Remove outdated test cases #147
Conversation
dcalhoun
force-pushed
the
docs/remove-outdated-test-cases
branch
from
7c19470
to
5157ffd
Compare
This test case is duplicative of the Group test case: https://github.com/wordpress-mobile/test-cases/blob/2389290ec634b25dcd19d1d2af3badcf8591ff4a/test-cases/gutenberg/group.md#tc009
These were automated in WordPress/gutenberg#49352.
This was automated in WordPress/gutenberg#45048.
These were automated in WordPress/gutenberg#49352.
dcalhoun
force-pushed
the
docs/remove-outdated-test-cases
branch
from
5157ffd
to
9f248b3
Compare
| **Highlight selected text** | ||
|
|
||
| - Write some text and select it. | ||
| - Tap on the Highlight text button (A). | ||
| - Select a color. | ||
| - Expect to see the text with the selected color. | ||
|
|
||
| **Highlight text without selection** | ||
|
|
||
| - Without selecting any text tap on the highlight text button (A). | ||
| - Select a color and write some text. | ||
| - Expect to see the newly introduced text with the previously selected color. |
There was a problem hiding this comment.
I checked the referenced automated tests and the test cases of the Paragraph block but couldn't find cases related to highlighting text. Hence, probably we should keep these two as manual until we automate them.
There was a problem hiding this comment.
Good catch. I added an integration test for highlighting with selection in WordPress/gutenberg#52446.
For highlighting without a selection, the typeInRichText helper does not support inner HTML tags, only outer HTML tags. Updating it to support inner HTML tags would get complicated really quickly, e.g. how might we handle typing with a text selection that begins within a tag but ends outside of it? Therefore, an e2e test likely makes more sense. I'll reinstate this case.
There was a problem hiding this comment.
For highlighting without a selection, the
typeInRichTexthelper does not support inner HTML tags, only outer HTML tags. Updating it to support inner HTML tags would get complicated really quickly, e.g. how might we handle typing with a text selection that begins within a tag but ends outside of it? Therefore, an e2e test likely makes more sense. I'll reinstate this case.
Good point, although I'm wondering if we need support for inner HTML tags for this case. If we just create a Paragraph block, tap the Highlight text button, and type text, I understand we wouldn't need to place the cursor between inner HTML tags in the assertion. Would this be an option? (I haven't tested this myself, so I might be overlooking an issue about inner HTML tags per your comment).
There was a problem hiding this comment.
If we just create a Paragraph block, tap the Highlight text button, and type text, I understand we wouldn't need to place the cursor between inner HTML tags in the assertion. Would this be an option? (I haven't tested this myself, so I might be overlooking an issue about inner HTML tags per your comment).
A mark tag is inserted once the Highlight text button is tapped. The next call of typeInRichText places the cursor at the end of the input (the expected default). However, the reality is that "the end" is after the closing mark tag. To counter this we either need to (A) add support for inner HTML tags or (B) manually adjust for the closing mark tag — e.g. targetPosition - lengthOfClosingMarkTag — which feels brittle and cryptic.
Inner HTML tag support would resolve the issue of difference between rendered string position (position in a visual representation after HTML is parsed and applied) vs literal string position (position in a raw string that includes HTML mark up).
There was a problem hiding this comment.
A mark tag is inserted once the Highlight text button is tapped. The next call of typeInRichText places the cursor at the end of the input (the expected default). However, the reality is that "the end" is after the closing mark tag.
Ah, true, I didn't realize that the mark tag was inserted upon tapping the button. I understand now the necessity of supporting the inner HTML tag. Thanks David for elaborating 🙇 !
To counter this we either need to (A) add support for inner HTML tags or (B) manually adjust for the closing mark tag — e.g.
targetPosition - lengthOfClosingMarkTag— which feels brittle and cryptic.
I agree that option A seems the best way to go 👍 .
Inner HTML tag support would resolve the issue of difference between rendered string position (position in a visual representation after HTML is parsed and applied) vs literal string position (position in a raw string that includes HTML mark up).
Maybe we could create a follow-up GitHub issue with this, so we can keep track of it. WDYT?
There was a problem hiding this comment.
I created WordPress/gutenberg#52520 capturing this enhancement.
These were automated in WordPress/gutenberg#49352. This test was left in place due to the known issues, but there is little value in doing so. The known issues are capture as individual issues in GitHub. https://github.com/wordpress-mobile/test-cases/pull/147/files#r1255412693
Our `typeInRichText` integration helper does not support parsing inner HTML tags. This is required in order to type at the correct cursor position, i.e. with the cursor placed within the `mark` tag that applies the text highlighting. Adding support for this gets complicated quickly, e.g. how might we support typing with a text selection the begins within a tag but finishes outside of it? Instead, adding an e2e test is likely the best approach.
Remove duplicative test cases or ones that have now been automated.
docs: Remove automated undo and redo test cases
These were automated in WordPress/gutenberg#49352.
docs: Remove automated List splitting and merging test
This was automated in WordPress/gutenberg#45048.
docs: Remove automated Rich Text cases
These were automated in WordPress/gutenberg#49352.
docs: Remove duplicative Dark Mode Group block test case
This test case is duplicative of the Group test case: https://github.com/wordpress-mobile/test-cases/blob/2389290ec634b25dcd19d1d2af3badcf8591ff4a/test-cases/gutenberg/group.md#tc009