Aman-Mittal opened a new pull request, #353:
URL: https://github.com/apache/fineract-backoffice-ui/pull/353

   Follow-up to #349, which made the suites recordable. The recordings it 
produced were unwatchable: every click, fill and navigation landed instantly, 
so a viewer saw the *result* of an action without ever seeing the action.
   
   ## The fix
   
   `slowMo` pauses before each Playwright operation, so the beat falls on the 
action rather than on the film. Gated on `DEMO_RECORD=1`, so the suite still 
runs at full speed and CI pays nothing; `DEMO_SLOW_MO` tunes it (default 450 
ms).
   
   **Only `full-demo.spec.ts` paced itself before, and it paused between 
*steps*.** Every other flow was filmed at full speed and stretched afterwards 
in post — which lengthens the footage without giving the eye anywhere to land. 
A slowed fast-forward is still a fast-forward. With the beat in the source, the 
post-processing slowdown drops to 1.0× entirely.
   
   Measured effect: the same 45 flows go from **9.8 min to 17.2 min** of 
footage.
   
   ## Two follow-on fixes, both the same defect
   
   A fixed timeout that pacing invalidates:
   
   - **`test.setTimeout` in 14 specs** overrides both the project and the root 
config, so a paced run would be cut off mid-flow and the clip would end on a 
frozen screen. `recordingTimeout()` in `e2e/fixtures.ts` scales those budgets 
while filming and returns them untouched otherwise — generalising the 
accommodation `full-demo.spec.ts` already made by hand.
   - **`captureJson()` hard-coded a 20 s window** for the intercepted response. 
A loan creation timed out waiting for its own POST and the clip ended on a 
stuck form. That budget now follows the recording too.
   
   Both were found by the recording failing, not by inspection.
   
   ## Docs
   
   `DOCS/DEMO.md` predated these switches, so the file that exists to explain 
the workflow didn't mention the one that makes a recording watchable. It now 
covers `DEMO_SLOW_MO`, why pacing is recorded rather than added in post, and 
two traps that cost real time here:
   
   - **Playwright clears `outputDir` at the start of every run** — re-recording 
one spec into the same directory deletes every other clip. (This is how I lost 
a full set of 45.)
   - **Don't change the working tree while a recording is in flight** — the dev 
server recompiles from source, so a checkout or rebase mid-run films a moving 
target.
   
   ## Verification
   
   - Specs behave identically at normal speed — `center-servicing.spec.ts` 3/3 
with no pacing set, and `lint` clean.
   - A full paced recording run produced 45 clips, 44 of which are stitched 
into a 16 min 48 s captioned walkthrough at 1280×720.
   - The 45th is excluded from the stitched video: its assertion failed because 
a seeded client sat beyond the visible rows after repeated runs against the 
same volume (test-data accumulation, not a product bug — it passes on a fresh 
database), so the clip doesn't show what its caption would claim.
   
   No production code is touched; the change is confined to the Playwright 
config, the e2e fixtures and their timeout call sites.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to