What's happening
The automated checks that run before every SAP-related code change (sap_pipeline, sap_sim_e2e) all exercise the same single, simple fake SAP screen (tests/support/sap_simulator.py's one VA01-shaped fixture). There's no modal/second-window screen and no table-control screen in the simulator.
If we don't fix it
Nothing but a human on the one real SAP machine the team has access to would notice if SAP support regresses — including the window-scoping fix from #475. That's slow, risky, and doesn't scale once a second team depends on this working.
If we fix it
The fake screen gains a couple more shapes (a wnd[1] modal, a classic table), so the automated checks catch these bugs by themselves, on every change, on any machine — not just in the maintainer-only sap_e2e tier.
Before closing
This issue is the test-coverage work — landing it means sap_sim_e2e gains real assertions against the new fixture shapes as its own proof of fix.
What's happening
The automated checks that run before every SAP-related code change (
sap_pipeline,sap_sim_e2e) all exercise the same single, simple fake SAP screen (tests/support/sap_simulator.py's one VA01-shaped fixture). There's no modal/second-window screen and no table-control screen in the simulator.If we don't fix it
Nothing but a human on the one real SAP machine the team has access to would notice if SAP support regresses — including the window-scoping fix from #475. That's slow, risky, and doesn't scale once a second team depends on this working.
If we fix it
The fake screen gains a couple more shapes (a
wnd[1]modal, a classic table), so the automated checks catch these bugs by themselves, on every change, on any machine — not just in the maintainer-onlysap_e2etier.Before closing
This issue is the test-coverage work — landing it means
sap_sim_e2egains real assertions against the new fixture shapes as its own proof of fix.