appId: xyz.blueskyweb.app --- - runScript: file: ../setupServer.js env: SERVER_PATH: "?users&follows" - runFlow: file: ../setupApp.yml # Login, create a thread, and log out - tapOn: id: "e2eSignInAlice" - extendedWaitUntil: visible: id: "viewHeaderHomeFeedPrefsBtn" - assertVisible: id: "composeFAB" - tapOn: id: "composeFAB" - inputText: "Test thread" - tapOn: id: "composerPublishBtn" # Wait for the composer to close and the home feed to settle before signing # out. Without a settle guard the next action can race the closing composer. - extendedWaitUntil: visible: id: "composeFAB" timeout: 10000 # Login, reply to the thread, and log out - tapOn: id: "e2eSignOut" - tapOn: id: "e2eSignInBob" - extendedWaitUntil: visible: id: "viewHeaderHomeFeedPrefsBtn" - tapOn: id: "replyBtn" # Wait for the composer to fully open before typing. - extendedWaitUntil: visible: id: "composerPublishBtn" timeout: 10000 - inputText: "Reply 1" - tapOn: id: "composerPublishBtn" # Wait for the composer to close before signing out. - extendedWaitUntil: visible: id: "composeFAB" timeout: 10000 # Login, confirm notification exists, mute thread, and log out - tapOn: id: "e2eSignOut" - tapOn: id: "e2eSignInAlice" - extendedWaitUntil: visible: id: "viewHeaderHomeFeedPrefsBtn" - tapOn: id: "bottomBarNotificationsBtn" - assertVisible: ".*Reply 1.*" - tapOn: ".*Reply 1.*" - tapOn: id: "postDropdownBtn" childOf: id: "postThreadItem-by-bob.test" - tapOn: "Mute thread" # Login, reply to the thread twice, and log out - tapOn: id: "e2eSignOut" - tapOn: id: "e2eSignInBob" - extendedWaitUntil: visible: id: "viewHeaderHomeFeedPrefsBtn" - tapOn: id: "bottomBarProfileBtn" - tapOn: id: "profilePager-selector-1" # Both replies target the thread root ("Test thread" by alice), which sits at # the top of bob's Replies tab. That tab renders each post in the thread with # its own replyBtn, so scope the tap to the root post's card # (feedItem-by-alice.test) rather than relying on which replyBtn Maestro picks # first. This keeps both reply taps deterministic regardless of list order or # how many posts have rendered. - tapOn: id: "replyBtn" childOf: id: "feedItem-by-alice.test" # Wait for the composer to fully open before typing. - extendedWaitUntil: visible: id: "composerPublishBtn" timeout: 10000 - inputText: "Reply 2" - tapOn: id: "composerPublishBtn" # Wait for the composer to close and the thread reply button to return before # opening the composer again. The replyBtn is effectively always present on this # screen, so waiting on its visibility alone does not gate on the composer close # animation or the author-feed re-render that follows a post. Without letting # those settle, the next replyBtn tap fires mid-transition and is swallowed, so # the composer never opens. Wait for the button, then for animations to end. - extendedWaitUntil: visible: id: "replyBtn" timeout: 10000 - waitForAnimationToEnd - tapOn: id: "replyBtn" childOf: id: "feedItem-by-alice.test" # Wait for the composer to fully open before typing. - extendedWaitUntil: visible: id: "composerPublishBtn" timeout: 10000 - inputText: "Reply 3" - tapOn: id: "composerPublishBtn" # Wait for the composer to close and the thread to settle before signing out. - extendedWaitUntil: visible: id: "replyBtn" timeout: 10000 # Login, confirm notifications dont exist, unmute the thread, ~~confirm notifications exist~~ # Mute thread behaviour no longer change old notifications after muting/unmuting a thread -sfn - tapOn: id: "e2eSignOut" - tapOn: id: "e2eSignInAlice" - extendedWaitUntil: visible: id: "viewHeaderHomeFeedPrefsBtn" - tapOn: id: "bottomBarNotificationsBtn" - assertVisible: ".*Reply 1.*" - assertNotVisible: ".*Reply 2.*" - assertNotVisible: ".*Reply 3.*" - tapOn: ".*Reply 1.*" - tapOn: id: "postDropdownBtn" childOf: id: "postThreadItem-by-bob.test" - tapOn: "Unmute thread" - tapOn: id: "bottomBarNotificationsBtn" - swipe: from: id: "notifsFeed" direction: DOWN - assertVisible: ".*Reply 1.*" - assertNotVisible: ".*Reply 2.*" - assertNotVisible: ".*Reply 3.*"