| name | verify-whole-feature-with-short-test-clip |
| description | Use when about to declare a dub-studio feature done or kick off a release, or the moment you catch yourself calling a real E2E "too heavy/slow/many segments" — finish and verify the WHOLE feature end-to-end first, and get real data by taking a short ffmpeg cut of an existing test_media file. |
Verify the whole feature on a real short clip — never excuse-out the E2E
When the user says "доделай / проверь что всё доделал / не бросил на полпути / потом релиз", they mean: every promised piece is finished AND proven end-to-end before you build the release. Enumerate the pieces (each backend path + each UI surface + each edge case) and check each — don't verify one path and call it done.
Get real test data — don't declare it "too heavy"
- Transcription in dub-studio is near-instant. There is a folder of
test_media/*.mp4. If an existing workspace project is large (e.g. 743 segments), that is NOT a reason to skip the test.
- Take a short segment of a test file and run the real flow on it:
ffmpeg -y -i test_media/<file>.mp4 -t 20 -c copy <scratch>/clip.mp4
then createProject → analyze (transcribe) → the feature under test.
- Saying "N segments is too heavy for a quick test" is the exact excuse the user rages at. Cut a clip and run it.
Don't mutate the user's real projects while testing
Copy a workspace project (or make a fresh one from a clip) to a throwaway pid; never run an in-place mutating endpoint (retranslate, patch, render) against the user's real workspace/<pid> during a test.
Related: [[verify-through-app-ui-not-scripts]], [[pre-release-check]], [[verify-from-clean-state-not-dev-machine]].
