feat: make JUnit XML id and classname attributes configurable

[dezsibalint]

Summary

• Adds optional id and classname keys to the flow YAML config section
• When present, they override the corresponding JUnit XML <testcase> attributes
• When omitted, behavior is unchanged — all three attributes default to flow.name

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" .../>

Closes #3151

Changes

File	Change
MaestroConfig.kt	Add id and classname fields + JS expression evaluation
YamlConfig.kt	Add YAML deserialization, pass to MaestroConfig
TestExecutionSummary.kt	Add nullable id and classname to FlowResult
TestSuiteInteractor.kt	Pass config values to FlowResult
JUnitTestSuiteReporter.kt	Use flow.id ?: flow.name and flow.classname ?: flow.name

Test plan

• New unit test: YAML config parsing with id and classname fields
• New unit test: JUnit XML output uses custom id/classname when present
• New unit test: JUnit XML output falls back to flow.name when fields are omitted
• All existing tests pass unchanged (backward compatible)

[Fishbowler]

Worth looking at the existing properties key, that's already solely for test reporting?

[dezsibalint]

@Fishbowler

Currently, id, name, and classname at the root level are all derived from the flow name, which results in three attributes carrying identical values. This is redundant and not very useful.

It can also break or confuse automated reporting tools that rely on these fields having distinct meanings. This PR addresses that by allowing them to be configured independently.

[dezsibalint]

AFAIK, properties just adds extra child elements under the root element, it doesn’t affect the root attributes.

[Fishbowler]

The properties don't currently affect id or classname. I was considering Maestro's surface area, and considering that the properties you're adding might better belong in the properties key rather than as top-level items. WDYT?

[dezsibalint]

@Fishbowler
I’d lean toward keeping them top-level.

The already optionally configurable name is top-level, and id / classname are closely related to that same testcase identity metadata. Since these fields directly affect the generated XML attributes rather than adding extra reporting properties, I think placing them next to name is more consistent and discoverable.

[Fishbowler]

Is there a better name we can give them? id is generic - it's not clear this is for test report generation only. classname is a legacy from Java-land which doesn't apply here, and won't make sense to folks who aren't JUnit afficionados.

[dezsibalint]

Good point, I’ll think about it and get back to you on Monday.

Since these are optional, we could also just clarify things in the docs and call it a day.

If you feel strongly about renaming, maybe something like reportId and reportClassname can be used?

[dezsibalint]

@Fishbowler Hi!
I moved all of it under properties, with junitId and junitClassname.