Use a macropad to move between test failures

KM16 Macropad can support test review by making result navigation easier to reach. The useful starting point is reading failures, not assigning a button that reruns everything whenever you are uncertain. A result panel, a stack trace and the affected source file each show different evidence. Your keypad layout should help move between them without losing the identity of the test run.

Which result interface do you use most?

Choose one interface for the initial profile: the editor's testing view, terminal output or a browser report. Record how you open the failure list and jump to a referenced file. If a test extension supplies the navigation commands, use its documented names and check that it is available in the current workspace.

A terminal log may not offer the same structured next-failure action as an editor view. In that case, mapping search or panel focus can be more reliable than trying to simulate a mouse click at a fixed position. The goal is a predictable destination, not an elaborate sequence.

Does the report belong to the code you are reviewing?

Before navigating, inspect the run's time, command or revision when the tool exposes them. A convenient failure list can still be stale. Keep a clear separation between opening the latest visible report and launching a new test run. They should not share an ambiguous label such as Check.

If your test process produces a saved report, establish how that report is replaced or refreshed. Do not let a keypad shortcut open an old file without a visible indication of its age. A physical control cannot determine whether the code changed after the results were produced.

Which commands belong together?

Group the failure list, source location, search and return-to-results actions. Keep rerun, stop and debug commands distinct because they change the process rather than merely the view. Start with application bindings that require no typed shell command and preserve your normal test controls while evaluating the layout.

For VS Code, the keybinding editor and diagnostic logging help identify whether a chord reaches the intended command. Test with focus in both the code pane and results pane, since context can change the result.

How can you evaluate the profile fairly?

Use a small known failing test, inspect its message and return to the result list. Try the same route after opening another panel. Keep notes on unclear transitions and remove mappings that require you to remember hidden focus state. See KM16 Macropad for setup requirements, and judge the profile by how clearly it supports evidence gathering rather than how many commands it stores.