Add UI tests to check the ability to scroll reader content and interact with the items #17536
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| import UITestsFoundation | ||
| import XCTest | ||
|
|
||
| class ReaderTests: XCTestCase { | ||
| private var readerScreen: ReaderScreen! | ||
|
|
||
| override func setUpWithError() throws { | ||
| setUpTestSuite() | ||
|
|
||
| _ = try LoginFlow.loginIfNeeded(siteUrl: WPUITestCredentials.testWPcomSiteAddress, email: WPUITestCredentials.testWPcomUserEmail, password: WPUITestCredentials.testWPcomPassword) | ||
tiagomar marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| readerScreen = try EditorFlow | ||
| .goToMySiteScreen() | ||
| .tabBar.goToReaderScreen() | ||
| } | ||
|
|
||
| override func tearDownWithError() throws { | ||
| takeScreenshotOfFailedTest() | ||
| if readerScreen != nil && !TabNavComponent.isVisible() { | ||
|
There was a problem hiding this comment. Just thinking aloud: as long as There was a problem hiding this comment.
The idea was to have it more generic but you are right about the |
||
| readerScreen.dismissPost() | ||
| } | ||
| try LoginFlow.logoutIfNeeded() | ||
| try super.tearDownWithError() | ||
|
There was a problem hiding this comment. It should not be necessary to call There was a problem hiding this comment. No, I have just followed what all the other tests were doing. I did try removing the It runs just fine when removing the whole line but I would be more comfortable removing it if I knew why it was added in first place. There was a problem hiding this comment. Ouch! My suggestions was not clear, sorry 😳 "to call If you updated to - try super.tearDownWithError()
+ try tearDownWithError()it will indeed got into an infinite loop. ♻️
Fair enough. Those methods are (should be?) empty in Feel free to ignore this. I plan to audit the test suite for this kind of stuff during my HACK week. 👍 #17569 |
||
| } | ||
|
|
||
| let expectedPostContent = "Aenean vehicula nunc in sapien rutrum, nec vehicula enim iaculis. Aenean vehicula nunc in sapien rutrum, nec vehicula enim iaculis. Proin dictum non ligula aliquam varius. Nam ornare accumsan ante, sollicitudin bibendum erat bibendum nec. Aenean vehicula nunc in sapien rutrum, nec vehicula enim iaculis." | ||
|
|
||
| func testViewPost() { | ||
| readerScreen.openLastPost() | ||
| XCTAssert(readerScreen.postContentEquals(expectedPostContent)) | ||
| } | ||
|
|
||
| func testViewPostInSafari() { | ||
| readerScreen.openLastPostInSafari() | ||
| XCTAssert(readerScreen.postContentEquals(expectedPostContent)) | ||
| } | ||
| } | ||
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.
This is a nice method. Probably better than the
scrollIntoView(within:, threshold:)we already have, because it doesn't rely on already knowing the scrollable container element.I might steal it 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.
I assume (I didn't test this) that this method is designed to scroll and wait for hittability of the last element only, because swiping up with fast velocity will probably will make it not suitable for the ones in the middle; and because it's called by
getLastPost().If this is so, what do you think of renaming the method to reflect this?