You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #5204. Child of the nightly Local E2E tracker. Do not close #5204 from this ticket; #5204 auto-closes when Local E2E Tests succeeds.
✅ Pre-submission Checklist
I have searched existing issues; no open ticket asks to replace the blocked public login sites with a repo-owned local HTML fixture.
This is not a configuration mistake. Nightly MacOSX_Safari_Local failed with a real locator miss after the remote page did not present the expected login form.
Local E2E GUI tests hit public websites. Those hosts rate-limit or block CI after too many requests. The nightly then fails on a missing element even though SHAFT's action code is fine.
Owner investigation of #5204: the target site is blocking us. Switch those tests to local HTML so the suite stays deterministic.
Confirmed evidence from MacOSX_Safari_Local on that run:
Root cause recorded as NoSuchElementException: Cannot locate an element using Smart Locator: "Username"
That test navigates to https://practicetestautomation.com/practice-test-login/ then types Username / Password and clicks Submit.
The same class already mixes remote sites (saucedemo.com, selenium.dev, moatazeldebsy.github.io) and one data:text/html fixture (testSmartLocators7). Continuity must not depend on a third-party host answering 200 with a login form.
Repeat a burst of that test against the live site (or wait for the next nightly). When the host blocks or serves a challenge page, "Username" is gone and the test breaks.
See error: Cannot locate an element using Smart Locator: "Username".
✅ Expected Behavior
Local E2E tests that only need a login form (or similar static markup) load a repo-owned HTML fixture. No public website is required for those cases. The same SHAFT actions still run: navigate, type Username, type Password, click Submit. Nightly MacOSX_Safari_Local does not fail because a third party blocked us.
❌ Actual Behavior
testSmartLocators2 depends on practicetestautomation.com. When that host blocks or changes, Allure records a broken Smart Locator "Username" and the nightly tracker #5204 stays open. Console/Allure do not distinguish "engine bug" from "remote site refused us."
User Story 1 - Local login fixture replaces the blocked host (Priority: P1)
Independent Test: Run SmartLocatorsTests.testSmartLocators2 offline or with the public host firewalled. It still finds Username / Password / Submit.
Acceptance Scenarios:
Given a repo-owned login HTML fixture with accessible name or label text Username, Password, and Submit, WhentestSmartLocators2 navigates to that fixture, Then type/click succeed without contacting practicetestautomation.com.
Given the same fixture, When Local E2E runs on Safari/Chrome/Edge, Then this test is not broken solely because a public host rate-limited CI.
User Story 2 - Sweep other public-only login/demo URLs in Local E2E (Priority: P1)
Independent Test: Inventory GUI tests in the Local E2E scope that navigate to third-party hosts only to exercise locators/actions.
Acceptance Scenarios:
GivenSmartLocatorsTests and other Local E2E classes that only need static markup (saucedemo v1 login, the-internet.herokuapp.com pages, selenium.dev/selenium/web/login.html when used only as a form), When the sweep lands, Then each such test has a local file:, data:, or served-from-repo HTML equivalent and no longer requires that host for green.
Given a test that truly needs a live network (authenticated cloud, paid third-party API), When the sweep classifies it, Then it stays tagged out of Local E2E rather than silently depending on a blockable demo site.
Edge Cases
Do not weaken or delete testSmartLocators2 to hide the nightly red. Change the target document, not the assertion that Username exists.
Keep Smart Locator text identical (Username, Password, Submit) so the test still proves the locator engine, not a new CSS id shortcut.
testSmartLocators7 already uses data:text/html. Prefer one shared fixture file over more inline data URIs if several tests need the same form.
Do not replace BrowserStack / cloud E2E targets. This ticket is Local E2E continuity only.
Do not treat a 200 challenge/captcha page as success; the fixture must actually contain the labeled controls.
Functional Requirements
FR-001: Add a repo-owned HTML login (and any other static pages the sweep needs) under test resources, served as file: or an equivalent local URL SHAFT already supports.
FR-002: Point SmartLocatorsTests.testSmartLocators2 at that fixture. Keep the Username / Password / Submit action sequence.
FR-003: Sweep Local E2E GUI tests that use public demo hosts only as markup sources; migrate those that do not need the live internet.
FR-004: Keep taxonomy labels valid (one primary, one lifecycle, at least one subsystem/module).
Success Criteria
SC-001: SmartLocatorsTests.testSmartLocators2 passes with the public login host unreachable.
SC-002: A documented inventory lists each migrated Local E2E URL and the tests left on the live internet, with a reason.
SC-003: Existing Smart Locator coverage is preserved, not deleted to go green.
Assumptions
Owner root cause for the Nightly failure: Local E2E Tests #5204 Safari break is remote blocking / an incomplete login page, not a Smart Locator regression.
https://www.selenium.dev/selenium/web/login.html may stay if it is stable; still inventory it. The required migrate is practicetestautomation.com.
Out of scope
Fixing Allure missing steps (sibling ticket).
Fixing the offline trace HTML viewer (sibling ticket).
Related to #5204. Child of the nightly Local E2E tracker. Do not close #5204 from this ticket; #5204 auto-closes when
Local E2E Testssucceeds.✅ Pre-submission Checklist
MacOSX_Safari_Localfailed with a real locator miss after the remote page did not present the expected login form.main(run 32208082103).🐛 Describe the Bug
Local E2E GUI tests hit public websites. Those hosts rate-limit or block CI after too many requests. The nightly then fails on a missing element even though SHAFT's action code is fine.
Owner investigation of #5204: the target site is blocking us. Switch those tests to local HTML so the suite stays deterministic.
Confirmed evidence from
MacOSX_Safari_Localon that run:testPackage.locator.SmartLocatorsTests.testSmartLocators2NoSuchElementException: Cannot locate an element using Smart Locator: "Username"https://practicetestautomation.com/practice-test-login/then types Username / Password and clicks Submit.The same class already mixes remote sites (
saucedemo.com,selenium.dev,moatazeldebsy.github.io) and onedata:text/htmlfixture (testSmartLocators7). Continuity must not depend on a third-party host answering 200 with a login form.🔁 Steps to Reproduce
MacOSX_Safari_Local.SmartLocatorsTests.testSmartLocators2broken on Smart Locator"Username".shaft-engine/src/test/java/testPackage/locator/SmartLocatorsTests.java—testSmartLocators2useshttps://practicetestautomation.com/practice-test-login/."Username"is gone and the test breaks.Cannot locate an element using Smart Locator: "Username".✅ Expected Behavior
Local E2E tests that only need a login form (or similar static markup) load a repo-owned HTML fixture. No public website is required for those cases. The same SHAFT actions still run: navigate, type Username, type Password, click Submit. Nightly
MacOSX_Safari_Localdoes not fail because a third party blocked us.❌ Actual Behavior
testSmartLocators2depends onpracticetestautomation.com. When that host blocks or changes, Allure records a broken Smart Locator"Username"and the nightly tracker #5204 stays open. Console/Allure do not distinguish "engine bug" from "remote site refused us."💻 Minimal Reproducible Code
🌍 Environment
mainat the #5204 nightly (f748d770ddera)MacOSX_Safari_Local)📋 Console Logs
Nightly job: https://github.com/ShaftHQ/SHAFT_ENGINE/actions/runs/32208082103/job/95935088978
Allure extract line: broken
testPackage.locator.SmartLocatorsTests.testSmartLocators2— Smart Locator"Username".User Scenarios & Testing
User Story 1 - Local login fixture replaces the blocked host (Priority: P1)
Independent Test: Run
SmartLocatorsTests.testSmartLocators2offline or with the public host firewalled. It still finds Username / Password / Submit.Acceptance Scenarios:
testSmartLocators2navigates to that fixture, Then type/click succeed without contactingpracticetestautomation.com.User Story 2 - Sweep other public-only login/demo URLs in Local E2E (Priority: P1)
Independent Test: Inventory GUI tests in the Local E2E scope that navigate to third-party hosts only to exercise locators/actions.
Acceptance Scenarios:
SmartLocatorsTestsand other Local E2E classes that only need static markup (saucedemov1 login,the-internet.herokuapp.compages,selenium.dev/selenium/web/login.htmlwhen used only as a form), When the sweep lands, Then each such test has a localfile:,data:, or served-from-repo HTML equivalent and no longer requires that host for green.Edge Cases
testSmartLocators2to hide the nightly red. Change the target document, not the assertion that Username exists.Username,Password,Submit) so the test still proves the locator engine, not a new CSS id shortcut.testSmartLocators7already usesdata:text/html. Prefer one shared fixture file over more inline data URIs if several tests need the same form.Functional Requirements
file:or an equivalent local URL SHAFT already supports.SmartLocatorsTests.testSmartLocators2at that fixture. Keep the Username / Password / Submit action sequence.Success Criteria
SmartLocatorsTests.testSmartLocators2passes with the public login host unreachable.Assumptions
https://www.selenium.dev/selenium/web/login.htmlmay stay if it is stable; still inventory it. The required migrate ispracticetestautomation.com.Out of scope
📝 Additional Context
Sibling of the Allure action-step ticket and the trace-viewer solidification ticket, both filed from the same #5204 investigation.