2063043 - Bug 2063043 - [efficiency] Convert SearchTest.verifyTabsSearchWithOpenTabsTest to ui/efficiency

Status: RESOLVED FIXED

(Firefox for Android :: UI Tests, task)

Description

[Jackie Johnson]

Converts SearchTest.verifyTabsSearchWithOpenTabsTest onto the ui/efficiency framework as
org.mozilla.fenix.ui.efficiency.tests.SearchTest#verifyTabsSearchWithOpenTabsTest.

Ported faithfully: entering the search bar, opening the search selector, selecting the temporary
"Tabs" search method, the negative suggestion check for "Mozilla", the clear button, the typed-toolbar
text check, the Firefox Suggest header, both open-tab suggestions, clicking the first suggestion, the
tab counter, and both tab-order assertions in the tab drawer.

Harness additions needed: four SearchBarSelectors entries (search shortcut, Firefox Suggest header,
suggestion row, clear button) plus a TabDrawerPage.verifyOpenTabsOrder() helper, since tab ordering
cannot be expressed with the mozVerify* family (they only answer "does any node match").

Parity notes (deviations, both equivalent-or-stricter):

1. Legacy verifySuggestionsAreNotDisplayed() matched the plural container tag
   "mozac.awesomebar.suggestions" with assertAny(hasText(x).not()), which passes as long as ANY node
   lacks the text and is therefore close to vacuous. The port asserts on the singular suggestion-row
   tag with mozVerifyNoneContainText, i.e. no row contains the text. Strictly stronger.
2. Legacy verifyTypedToolbarText() reads the search box's semantics config with whitespace
   normalization; the port does a substring text match against the same node.

Environment note worth flagging separately: this test's suggestion assertions match on the tab URL,
and that only works because SearchMockServerRule's dispatcher 404s everything except
searchResults.html. The tabs therefore never load, have no title, and the awesomebar row falls back to
rendering the URL. Pointed at a mock server that actually serves the asset, the row shows the page
title ("Test_Page_1") instead and the same assertions cannot match. The port keeps SearchMockServerRule
so the legacy assertions carry over verbatim, but the dependency is accidental rather than intended.

Verified green and clean on a headless Medium_Phone(AVD) API 37 emulator (effverify: ok=true,
clean=true, failed_total=0, retried=false).

Why: Migrate a legacy Fenix smoke test onto the ui/efficiency framework as part of the TAE conversion campaign.

Context: part of the ui/efficiency UI-test modernization. This is a faithful port of an existing legacy ui/ smoke test onto the ui/efficiency framework — same coverage and assertions, but far less per-test code via a shared page-object / selector / navigation layer, which bends the UI-test maintenance cost curve. Smoke-conversion campaign.

TestRail: 2154199

Comment 1

[Jackie Johnson]

Attachment: Bug 2063043 - [efficiency] Convert SearchTest.verifyTabsSearchWithOpenTabsTest to ui/efficiency r=isabel_rios,aaronmt

Ports the legacy smoke test onto ui/efficiency and annotates the legacy method
with @Converted.

Harness additions: four SearchBarSelectors entries (search shortcut, Firefox
Suggest header, suggestion row, clear button) and TabDrawerPage.verifyOpenTabsOrder(),
since tab ordering cannot be expressed with the mozVerify* family - those only
answer "does any node match", not "which position is it in".

Two deliberate deviations from the legacy assertions, both equivalent or stricter:
the negative suggestion check asserts that no suggestion row contains the term,
where legacy matched the plural container tag with assertAny(hasText().not()) and
so passed whenever any node lacked the text; and the typed-toolbar check is a
substring text match rather than a normalized semantics read.

The URL-based suggestion assertions only hold because SearchMockServerRule's
dispatcher 404s everything except searchResults.html, so the tabs never load, have
no title, and the awesomebar row renders the URL instead. The port keeps that rule
so the legacy assertions carry over verbatim; the dependency is accidental rather
than intended and is worth revisiting separately.

Comment 2

[Takanori MATSUURA]

Why do you go out of your way to add the bug number in your bug report summaries when almost no one else does that for their bugs?

Is it simply for aesthetics, to make them match the changset summaries?
If so, it's pointless.

Comment 3

[Jackie Johnson]

i was told it was a hard requirement to include it. that's why.(In reply to Takanori MATSUURA from comment #2)

Why do you go out of your way to add the bug number in your bug report summaries when almost no one else does that for their bugs?

Is it simply for aesthetics, to make them match the changset summaries?
If so, it's pointless.

i was told it was a hard requirement. that's why. if i was lied to, cool, i can stop.

Comment 4

[Takanori MATSUURA]

(In reply to Jackie Johnson from comment #3)

i was told it was a hard requirement to include it. that's why.

i was told it was a hard requirement. that's why. if i was lied to, cool, i can stop.

I'm not an internal member of the project, so I can't really say either way.
If it's something you were explicitly told to do, whether it's documented somewhere or just an internal convention, then it makes sense to keep doing it.
I just haven't seen anyone except you do it, so it looked unusual from the outside.
I was worried that the requirement intended for Phablicator's summary would also apply to Bugzilla's summary.
That's all I was curious about.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2694497550fd
https://hg.mozilla.org/integration/autoland/rev/8f54eae832f4
[efficiency] Convert SearchTest.verifyTabsSearchWithOpenTabsTest to ui/efficiency r=aaronmt

Comment 6

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/8f54eae832f4