Make test results attributes configurable

[dezsibalint]

Use case

In JUnitTestSuiteReporter.kt, the JUnit XML element's id, name, and classname attributes are all hardcoded to flow.name:

  TestCase(
      id = flow.name,
      name = flow.name,
      classname = flow.name,
      ...
  )

The name field is already configurable via the YAML config section (defaults to the filename when not specified). However, id and classname are not independently configurable.

This is limiting for CI/CD integrations that rely on these JUnit XML attributes for test identification, grouping, and linking to external test management tools. For example, classname is commonly used for
package-based grouping, and id for unique test case identifiers.

Proposal

Introduce two new optional keys in the flow YAML config section: id and classname. They follow the same pattern as name — optional, with flow.name as the default value when omitted.

YAML example:

  name: Login Test
  id: TC-LOGIN-001
  classname: com.example.tests.LoginTest
  appId: com.example.app
  ---
  - launchApp

Produces:

  <testcase id="TC-LOGIN-001" name="Login Test" classname="com.example.tests.LoginTest" .../>

When id/classname are omitted, behavior is identical to today — all three attributes use flow.name.

Backward Compatibility

Fully backward compatible. Both fields are optional with null defaults. Existing YAML files without id or classname produce exactly the same output as before.

Implementation Plan

6 files across 3 modules, listed in dependency order:

1. MaestroConfig.kt — Domain model

maestro-orchestra-models/src/main/java/maestro/orchestra/MaestroConfig.kt

• Add val id: String? = null and val classname: String? = null to the data class constructor (after name)
• Add id = id?.evaluateScripts(jsEngine) and classname = classname?.evaluateScripts(jsEngine) in evaluateScripts() to support JS expression evaluation

2. YamlConfig.kt — YAML deserialization

maestro-orchestra/src/main/java/maestro/orchestra/yaml/YamlConfig.kt

• Add val id: String? = null and val classname: String? = null to the data class constructor (after name)
• In toCommand(), pass id = id and classname = classname to MaestroConfig()

3. TestExecutionSummary.kt — Flow result model

maestro-cli/src/main/java/maestro/cli/model/TestExecutionSummary.kt

• Add val id: String? = null and val classname: String? = null to FlowResult (after name)
• Nullable with null defaults so existing call sites (CloudInteractor, tests) continue to compile without changes

4. TestSuiteInteractor.kt — Resolve values from config

maestro-cli/src/main/java/maestro/cli/runner/TestSuiteInteractor.kt

After the existing flowName resolution:

  val flowId: String? = maestroConfig?.id
  val flowClassname: String? = maestroConfig?.classname

5. JUnitTestSuiteReporter.kt — Use new fields with fallback

maestro-cli/src/main/java/maestro/cli/report/JUnitTestSuiteReporter.kt

  // Before
  id = flow.name,
  name = flow.name,
  classname = flow.name,

  // After
  id = flow.id ?: flow.name,
  name = flow.name,
  classname = flow.classname ?: flow.name,

Anything else?

No response

[linear]

MAE-440

[Fishbowler]

I don't know if these should be top-level entries in a flow. Maybe these should work similar to the properties in #2979, by nesting under a top level field? Or perhaps the implementation there should allow for specially named properties of id and classname?

[dezsibalint]

@Fishbowler Good point, my reasoning was that name is already a top-level config key, and id/classname serve the same purpose

[dezsibalint]

Hi @Fishbowler , just wanted to follow up on this 🙂

Do you have any thoughts on whether id and classname should remain top-level like name, or if you'd prefer another solution ?

Also, please let me know if you'd like me to take this on.
I'm happy to implement it, but equally fine if this is something you'd prefer to handle internally.

Happy to adjust the proposal either way, just want to make sure it aligns with the direction you have in mind before moving forward with the implementation. Thanks!