Skip to content

test(ui): fix DependsOnHarmoniaIT caption assertion (ORDERS -> Orders) broken by #6361 - #6372

Merged
delchev merged 1 commit into
masterfrom
fix/dependson-harmonia-caption-casing
Jul 22, 2026
Merged

test(ui): fix DependsOnHarmoniaIT caption assertion (ORDERS -> Orders) broken by #6361#6372
delchev merged 1 commit into
masterfrom
fix/dependson-harmonia-caption-casing

Conversation

@delchev

@delchev delchev commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Problem

master is red — the Build workflow's integration-tests (h2 and postgresql) fail on:

DependsOnHarmoniaIT>PredefinedProjectIT.test:28
  Element by [By.tagName: span] and conditions [[exist, match text "ORDERS"]] cannot be found in any iframe.
Tests run: 203, Failures: 1

Cause

#6361 (unify page/record title styling) rewrote the manage form-view caption from

x-text="T(..., '${entityLabel}').toUpperCase()"

to

x-text="T(..., '${entityLabel}')"

dropping the force-uppercase so the form caption matches the (non-uppercased) document-title style it was unified with. The rendered DOM text is now Orders, but DependsOnHarmoniaTestProject still asserted the old all-caps ORDERS (Selenide reads DOM text, not CSS), and the test was not updated in #6361. It is the only source assertion affected (verified by grep over tests/**).

Fix

Assert the resolved human label Orders. The test's documented intent — that the generator derives a real label rather than leaving the raw ${ENTITYLABEL} placeholder — is unchanged; Orders still proves resolution. Also refreshed the now-stale "(uppercased)" comment.

Verification

tests/tests-integrations test-compiles. The full Selenide UI suite (~2h) was not re-run locally; the change is a deterministic string-literal correction matching the caption the current template emits (confirmed against the form-view and document-view templates on master).

#6361 unified the form caption to the document-title style and dropped the
force-uppercase (.toUpperCase()), matching the non-uppercased document
layout - but this UI assertion still expected the old all-caps 'ORDERS' and
was left red on master. Assert the resolved human label 'Orders' instead;
the test's intent (the generator derives a real label, not the raw
${ENTITYLABEL} placeholder) is unchanged. Only source assertion affected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@delchev
delchev merged commit f8a78aa into master Jul 22, 2026
10 checks passed
@delchev
delchev deleted the fix/dependson-harmonia-caption-casing branch July 22, 2026 09:58
delchev added a commit that referenced this pull request Jul 22, 2026
…re (#6388)

The test asserted exactly one <span> containing 'Orders' as the create-form
caption. Since the fixture entity is named 'Orders', its derived entityLabel
(the form caption) equals its menuLabel (the list toolbar title), and #6361
unified both to caption <span>s - so the label legitimately renders in two
places and the ExistsByTypeAndContainsText finder (which rejects >1 match)
fails with 'Found [2] ... expected at most one'. (#6372 surfaced it by
lowercasing the form caption to match the list title's 'Orders'.)

The assertion's real intent is that the generator DERIVED the label rather
than leaking the literal ${ENTITYLABEL}; assert that placeholder is ABSENT
instead - count-immune, and the form rendering + label resolution stay proven
by the Country/City depends-on assertions that follow.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant