feat(ui5-test-writer): Generate Object Page Title test

[sap-sebelao]

Internal issue
36742
Internal JIRAs
FXUBRQ34-12490

[changeset-bot]

🦋 Changeset detected

Latest commit: e69f090

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@sap-ux/ui5-test-writer	Minor
@sap-ux/fiori-elements-writer	Patch
@sap-ux/fiori-freestyle-writer	Patch
@sap-ux/fiori-app-sub-generator	Patch
@sap-ux/repo-app-import-sub-generator	Patch
@sap-ux/generator-simple-fe	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[hyperspace-pr-bot]

Summary

The following content is AI-generated and provides a summary of the pull request:

---

Description

Adds support for generating an Object Page header title check test (iCheckTitlePath) in the @sap-ux/ui5-test-writer package. When an Object Page's header title is bound to an OData property path (via annotation), the generated integration test journey file will now include an OPA test step that verifies this title binding using iCheckTitlePath.

Changes overview:

• modelUtils.ts: Introduced a new HeaderItem interface to type the header aggregation node including optional title/description properties. Also updated the readApp call to include includeAnnotationProperties: true, which makes annotation-derived data (such as the title binding) available in the app model.

• objectPageUtils.ts: Added a new getHeaderTitlePath() function that reads the header aggregation's properties.title.value from the Object Page model and returns the OData property path for use with iCheckTitlePath. The extracted path is set on pageFeatureData.headerTitle.

• Templates (ObjectPageJourney.js / ObjectPageJourney.ts): Added a new conditional OPA test block — "Check header title of the Object Page" — that calls iCheckTitlePath with the resolved binding path. This block is only emitted when a headerTitle is present.

• Test data (constants.ts): Updated V4_WITH_SUB_OBJECT_PAGE model to include properties.title.value for the TravelObjectPage ("TravelID") and BookingObjectPage ("BookingID") headers.

• Tests: Added unit tests for getHeaderTitlePath covering cases where the title binding is present and where it is absent. Also added an integration-level assertion that the generated journey file contains the iCheckTitlePath("BookingID") call.

Type of change

• New feature (non-breaking change which adds a new feature)
• Bug (non-breaking change which fixes an issue)
• Breaking change (Bug or New feature that would cause existing functionality/consumers to not work as expected)
• Non-Breaking chores (Changes to tools, libraries, build process, documentation, etc)
• None of the above (Reviewers might ask for more clarification)

How have you tested?

• Added unit tests for getHeaderTitlePath in objectPageUtils.test.ts covering both the presence and absence of a title binding path.
• Added an integration-level test assertion verifying the generated BookingObjectPageJourney.gen.js contains onHeader().iCheckTitlePath("BookingID").
• Updated test model constants to include the title property data needed for the new feature.

Checklist:

• The code conforms to the general development principles
• Supplied as many details as possible on this change
• The code is easy to read and maintainable by others
• Corresponding changes to the documentation has been done
• Already existing and new unit tests pass locally

---

• 🔄 Regenerate and Update Summary
• ✏️ Insert as PR Description (deletes this comment)
• 🗑️ Delete comment

PR Bot Information

Version: 1.29.6

• File Content Strategy: Full file content
• LLM: anthropic--claude-4.6-sonnet
• Output Template: Repository PR Template
• Event Trigger: pull_request.ready_for_review
• Correlation ID: 61576cc0-8b50-11f1-91bd-525132c05b69
• Summary Prompt: Default Prompt

[hyperspace-pr-bot]

The PR introduces a useful feature but has a few issues worth addressing: the includeAnnotationProperties type intersection is a silent runtime escape hatch that could hide future API incompatibilities, both EJS templates use unescaped <%- interpolation for headerTitle which would produce syntax errors in generated files if a title path ever contains a double-quote, and the integration test only validates the sub-object-page (BookingObjectPage) title assertion while leaving the parent (TravelObjectPage) title path untested despite the updated test constant.

PR Bot Information

Version: 1.29.6

• Agent Instructions:
  • AGENTS.md
  • CLAUDE.md
• File Content Strategy: Full file content
• LLM: anthropic--claude-4.6-sonnet
• Experiment Variant: control
• Event Trigger: pull_request.ready_for_review
• Correlation ID: 61576cc0-8b50-11f1-91bd-525132c05b69

[sap-sebelao]

see comments +

In the generated journey, the new title check block is inserted after the navigate to page test but before header facets. This seems correct. However it's worth confirming: does iCheckTitlePath require the page to be in display mode (not edit mode)? If edit mode is possible as an initial state (I think it can be with some custom extension), the generated test could be fragile.

Looked into the assertion implementation - iCheckTitlePath is looking for ObjectPageDynamicHeaderTitle which is always present, and then checks the actual binding path value, it should by all means be able to work even in edit mode, but I did not actually test it yet.

Custom implementation would be out of scope for the generator anyway, but edit mode can actually be active even without any custom implementation - in LROP with enabled draft, if the mockdata entry is marked as draft entry, it will auto open in edit mode. I ran into this issue earlier when implementing tests for Actions, and had to resort to generating one assertion commented out. (EDIT: the line(s) in question: https://github.com/SAP/open-ux-tools/blob/main/packages/ui5-test-writer/templates/v4/1.150/integration/ObjectPageJourney.js#L47)

One agreed upon limitation is that the generator does not read the mockdata, so it is up to the app developers to adjust which entry is being opened, if the default one (index 0) does not fit the generated test.

If the title test would be failing on edit mode (which I dont think based on the assertion implementation), we would anyway only be able to at best add a comment to instruct the developers to adjust the opened object page entry to a non-edit mode one - or we would have to generate this whole test case commented out, again for the app devs to decide if they can use it.

[heimwege]

• changeset ok
• review comments addressed
• coverage is excellent
• did NOT test manually

[devinea]

Changes are clear and covered by tests.
Did not test locally
changeset ✅

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud