Automated test fails due to missing fields in schedule manager Fiori app

Our automated regression test suite is failing on the schedule manager Fiori app after we extended it with custom fields. Tests that create and validate schedules can’t locate the new fields, causing assertion failures.

The custom fields appear correctly in the UI when tested manually, but Selenium WebDriver can’t find them. We extended the standard app using UI5 flexibility and added fields for cost center and project code.

Test error output:


Element not found: input[id*='customCostCenter']
Timeout waiting for element visibility
Test case: Create_Schedule_With_Project failed

The OData service metadata shows the new fields, and the Fiori app renders them. But our automated tests, which worked before the extension, now fail. We need to understand if this is an OData metadata issue, UI5 rendering timing, or if our test selectors need updating for extended Fiori apps.

Your automated test failures highlight three interconnected challenges with testing extended Fiori applications. Here’s a comprehensive solution addressing each layer:

1. Fiori UI5 Extension Impact on Test Automation: UI5 flexibility extensions introduce dynamic element generation that breaks traditional Selenium selectors. When you extend a standard Fiori app, the framework:

  • Generates unique view IDs for each session/instance
  • Applies extension fragments asynchronously after base app loads
  • Creates composite IDs combining view prefix + control ID + suffix
  • May render controls in different DOM positions than expected

Your error shows the classic symptom: input[id*='customCostCenter'] fails because the actual ID is __xmlview2--customCostCenter-inner which changes between test runs.

2. Automated Test Script Maintenance Strategy: Implement a three-tier selector strategy:

Tier 1 - Add Stable Test Attributes (Development Phase): Modify your UI5 flexibility extension to include test hooks:

<Input id="customCostCenter"
       value="{CostCenter}"
       data-test-id="schedule-cost-center"
       data-test-type="input"/>

This requires updating your extension definition but provides maximum stability.

Tier 2 - UI5-Aware Selectors (Current Tests): Update Selenium tests to use UI5-specific selector patterns:

// Instead of exact ID match
driver.findElement(By.id('customCostCenter'))

// Use partial match with control-specific suffix
driver.findElement(By.css('[id$="customCostCenter-inner"]'))

// Or use UI5 control properties
driver.findElement(By.css('input[data-sap-ui*="CostCenter"]'))

Tier 3 - Smart Waits for Async Rendering: Implement UI5-aware wait conditions:

const waitForUI5Ready = async () => {
  await driver.wait(() => {
    return driver.executeScript(
      'return window.sap && sap.ui.getCore().isInitialized()'
    );
  }, 10000);

  await driver.wait(() => {
    return driver.executeScript(
      'return sap.ui.getCore().getUIDirty() === false'
    );
  }, 5000);
};

3. OData Service Metadata Synchronization: Verify the backend metadata reflects your extensions:

Check metadata exposure:


/sap/opu/odata/sap/ZSCHEDULE_SRV/$metadata

Look for your custom properties:

<Property Name="CostCenter" Type="Edm.String" MaxLength="10"/>
<Property Name="ProjectCode" Type="Edm.String" MaxLength="24"/>

If missing, the UI5 extension might be client-side only. For proper testing, extend the OData service backend:

  • Extend CDS view to include custom fields
  • Regenerate OData service with transaction SEGW
  • Clear metadata cache in /IWFND/MAINT_SERVICE
  • Refresh Fiori app metadata in /UI5/APP_INDEX_CALCULATE

Comprehensive Test Suite Update:

Phase 1 - Immediate Fix (works with current code): Update test selectors to use suffix matching and add explicit waits:

await waitForUI5Ready();
const costCenterField = await driver.findElement(
  By.css('input[id$="customCostCenter-inner"]')
);
await driver.wait(until.elementIsVisible(costCenterField), 5000);
await costCenterField.sendKeys('CC-12345');

Phase 2 - Sustainable Solution (requires dev coordination):

  1. Add data-test-id attributes to all custom UI5 controls
  2. Create a test selector library mapping logical names to test IDs
  3. Implement page object pattern with UI5-aware element location
  4. Add metadata validation tests that verify OData service exposes custom fields
  5. Create UI5 initialization helpers for consistent wait strategies

Phase 3 - Framework Migration (long-term): Consider migrating to UI5-native test frameworks:

  • UIVeri5: SAP’s official UI5 test framework with built-in control recognition
  • Wdi5: WebDriver bridge for UI5 with selector API based on control properties
  • OPA5: For unit/integration testing during development

These frameworks understand UI5 control lifecycle and extension mechanisms, eliminating selector brittleness.

Root Cause Summary: Your tests fail because:

  1. UI5 flexibility generates dynamic IDs that change between sessions
  2. Extension controls render asynchronously after base app initialization
  3. Selenium’s standard waits don’t account for UI5’s rendering lifecycle
  4. Test selectors assume static IDs from standard (non-extended) apps

The solution requires both immediate selector fixes and architectural changes to your test framework for long-term maintainability of extended Fiori app testing.


This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

When you extend Fiori apps with UI5 flexibility, the element IDs often get dynamically generated with different patterns than standard fields. Check the browser inspector to see the actual IDs being generated for your custom fields. They might have prefixes like ‘__xmlview0–’ or similar. Your Selenium selectors need to account for these dynamic ID patterns, possibly using partial matching or data attributes instead of exact ID matches.

Inspected the elements - you’re right, the IDs are dynamically generated with view prefixes. The custom cost center field has ID ‘__xmlview2–customCostCenter-inner’ in one test run and ‘__xmlview3–customCostCenter-inner’ in another. How do we write stable selectors for UI5 flexibility extensions? Should we add custom data attributes to the extension definition?

Best practice for testing extended Fiori apps is to add stable test IDs during the extension development. In your UI5 flexibility change, add custom data attributes like ‘data-test-id=“costCenter”’. Then your Selenium tests can use CSS selectors like ‘[data-test-id=“costCenter”]’ which remain stable regardless of dynamic ID generation. This requires coordination between developers and QA to establish a testing attribute standard.

Also verify the OData service metadata refresh. If your tests query the metadata to discover available fields, the extension might not be properly registered in the service. Check transaction /IWFND/MAINT_SERVICE to ensure your extended entity set shows the new properties. The metadata cache might need clearing in your test environment for the OData service to reflect the UI5 flexibility changes.

Another consideration is the timing of when UI5 flexibility extensions are applied. The custom fields might render after your test’s initial page load check. Add explicit waits in your Selenium tests for the UI5 application to fully initialize. Use WebDriverWait with a condition that checks for a specific UI5 control to be rendered, not just DOM ready. UI5 apps have asynchronous rendering that standard Selenium waits don’t account for.

Tested this on S/4HANA 2023 with UI5 flexibility extensions in Schedule Manager, and switching from static Selenium selectors to stable data-sap-ui IDs eliminated our composite ID breakages immediately.

Consider using UI5 test automation tools like UIVeri5 or Wdi5 instead of plain Selenium for Fiori apps. These frameworks understand UI5 control lifecycle and can reliably interact with extended apps. They provide selectors based on UI5 control properties rather than DOM IDs, making tests more stable across extensions and UI5 version updates.