Test DAS Hotkey Scripts and Recover Deliberately
Make a reproducible case before trusting a script.
Build a test ladder
Start with pure arithmetic, then object inspection, then UI loading, then a bounded simulator order test designed for the specific broker/build. Passing one step does not prove the next. Replay and simulator behavior also do not establish live execution quality.
| Test | Expected observation | Evidence |
|---|---|---|
| Equal price inputs | Invalid distance path | Inputs and displayed message |
| Window renamed | Dependency failure characterized | Build and exact symptom |
| Different focused window | Named target remains explicit | Target and displayed symbol |
| Missing quote | No valid calculation presented | Feed status and result |
| Two quick triggers | Repetition behavior characterized | Invocation times and state |
| Partial fill / rejection | Reconciliation or manual stop | Order records and timestamps |
| Disconnect / restart | Prepared state invalidated | Before/after state |
Debug by narrowing the boundary
When a value is wrong, inspect the source object before changing the formula. When a command is rejected, separate parsing, window context, account permissions, route support and broker response. Preserve the exact error and build; do not classify every failure as a syntax error.
A minimal release record
Keep script version, exact text, build, environment, dependencies, expected results, observed results and known limitations. Back up desktop and hotkeys together. On an update, disable periodic entry points, install the change and repeat the relevant tests before re-enabling them.
Lab: write a useful failure report
Choose one failure case. Include the smallest script, sanitized setup, expected behavior, actual behavior and recovery steps. Label assumptions separately from observations. “It worked yesterday” is a starting clue; a reproducible record is evidence someone else can review.
Separate evidence levels
| Level | Establishes | Does not establish |
|---|---|---|
| Documentation review | Traceable signatures and fields | Support in your build |
| Static reading | Clear inputs, branches, outputs and effects | Successful runtime parsing |
| Fixed-input client exercise | Local behavior for stated inputs | Feed, account or broker behavior |
| Simulator integration | Target windows, events and reports agree | Equivalent live execution |
Website builds, copy-button tests and quizzes are not DAS execution tests. This course explicitly retains client-testing-pending status; future records must preserve that distinction.
A minimal failure report
“Expected 100, observed 0” is more useful than “the script broke.” Include minimal source, build, entry point, window name, account environment, fixed inputs, last confirmed execution point and object inspection. Remove events and external actions first, preserve the smallest reproducer, and restore dependencies one at a time.
A trailing Wait cannot repair duplicate helper names, stale globals or a changed desktop. It changes timing without correcting object identity or providing broker acknowledgement.
Recovery and worked answer
Stop repeating entry points, preserve observations, disable actions, reconcile external outcomes, clean up owned state, then initialize again. Deleting an object still read by an active Timer is not a stop procedure.
A valid → invalid → valid input sequence must produce valid result → unavailable → new valid result. If the middle step still exposes the first result, validity or cleanup is broken even if the isolated formula works. Include this sequence in every project acceptance record.