Keyboard Shortcuts and Habits That Save Real Time

I've watched testers open the command palette exactly once, decide it's faster to just click, and never touch it again. That's a pattern I've seen repeat itself across teams of every size, and it quietly costs people thirty to sixty minutes a day in aggregate friction — tiny pauses that never feel like a problem until you add them up. Keyboard shortcuts aren't about looking cool in a screen recording; they're about keeping your hands in the code and your brain in the problem.

The habits I'm covering here are the ones I actually reach for when writing and debugging API tests in VS Code with Python, Behave, and pytest. Some are pure shortcuts. Some are workflow patterns — the kind of thing that doesn't have a keybinding but still saves real time because it removes a decision or a context switch. I'll show you the concrete keystrokes, explain why each one matters in a testing workflow specifically, and flag the mistakes I see people make when they skip them.

None of this requires a plugin overhaul or a new tool. Everything below works with a stock VS Code install and a standard Python test project. If you're already comfortable with the basics, I'll push into the habits that separate a fast tester from a slow one — the ones that compound over a week of work.

The VS Code Shortcuts That Matter Most Inside a Test File

Let's start where you spend most of your time: inside a test file. Here are the shortcuts I use constantly and why each one earns its place in a testing workflow.

Ctrl+P / Cmd+P — Quick Open

This is the single highest-ROI shortcut in VS Code. Instead of clicking through the file explorer to get from your features/ directory to a steps/ file, you type the first few characters of the filename and you're there. In a typical Behave project with a dozen feature files and matching step definition files, this alone eliminates a surprising amount of sidebar hunting. Type Ctrl+P, then steps/auth, and you're in your authentication step definitions in under a second.

Ctrl+Shift+P — Command Palette

The command palette is where everything else lives. Format document, run a specific test, toggle the terminal, change the Python interpreter — all of it is one shortcut and a few characters away. I use Python: Run Current File in Terminal from here constantly when I want to fire a single test script without switching to the terminal manually.

Ctrl+` — Toggle the Integrated Terminal

Switching between editor and terminal with the mouse is a habit that kills flow. Ctrl+` (backtick) opens and closes the terminal panel instantly. Pair it with Ctrl+Shift+` to create a new terminal instance, and you can have one terminal running your test suite and another free for git commands or inspecting a response payload.

Alt+Up / Alt+Down — Move Lines

When you're reordering assertions or rearranging steps in a scenario, moving lines with the keyboard is dramatically faster than cut-and-paste. Select a block, hold Alt, and tap the arrow. This is one of those shortcuts that feels trivial until you've used it for a week and then try to work without it.

Ctrl+D — Select Next Occurrence

You have an endpoint URL repeated five times in a step definition file and you need to rename it. Hit Ctrl+D repeatedly to select each occurrence in sequence, then type the replacement. This is safer than a global find-and-replace when you only want to change occurrences in a specific context — a common situation when you have similar variable names across different test scenarios.

Ctrl+Shift+L — Select All Occurrences

The nuclear version of Ctrl+D. When you genuinely want every instance of a selected word changed at once — say, renaming a base URL constant across a file — this puts a cursor on all of them simultaneously.

Ctrl+/ — Toggle Line Comment

Commenting out a step or an assertion to isolate a failure is something I do constantly during debugging. Ctrl+/ toggles the comment on the current line or selection without touching the mouse. Small thing, used dozens of times a day.

Multi-Cursor Editing: Alt+Click

Click to place your primary cursor, then Alt+Click to place additional cursors anywhere in the file. This is invaluable when you need to add the same import or the same assertion prefix to several non-contiguous lines at once. In pytest parametrize blocks especially, I reach for this constantly.

Common mistake: People learn Ctrl+D but forget that pressing Ctrl+D once selects the current word, and pressing it again selects the next occurrence. They select the word manually first, which wastes the first keypress. Just put your cursor in the word and hit Ctrl+D twice.

Navigation Habits That Keep You Out of the Mouse

Shortcuts are one thing. The habits that connect them are what actually change your speed. Here's how I navigate a test project without touching the mouse for stretches of ten or twenty minutes at a time.

Go to Definition and Back: F12 and Alt+Left

In a Behave project, your step definition might call a helper function in a separate utils/ module, which in turn calls a shared fixtures file. F12 jumps to the definition of whatever your cursor is on. Alt+Left (or Ctrl+- on Mac) jumps back. This navigation pair is the fastest way to trace a failure through multiple files without losing your place. I use it constantly when debugging why a particular API assertion is failing — jump into the helper, check the response parsing logic, jump back to the step.

Go to Symbol in File: Ctrl+Shift+O

In a long step definitions file, Ctrl+Shift+O opens a list of every function and class in the current file. Type a few characters to filter. This beats scrolling every time. Prefix with @ to group by category if your file has both classes and functions.

Go to Symbol in Workspace: Ctrl+T

The workspace-wide version of the above. When you can't remember which file a particular fixture or helper function lives in, Ctrl+T and a few characters will find it. This is the shortcut that makes a well-named codebase feel small.

Split Editor: Ctrl+\

When I'm writing a new test scenario in a .feature file, I want the corresponding step definitions file open side-by-side. Ctrl+\ splits the editor, then Ctrl+P in the new pane to open the step file. Now I can write the Gherkin on the left and implement the step on the right without any switching. This is the single layout habit I recommend most to testers who are new to Behave.

Breadcrumb Navigation

The breadcrumb bar at the top of each editor pane shows your current file path and the symbol your cursor is inside. Clicking any segment navigates up the tree. Most testers ignore this entirely. I use it to quickly confirm which class or function I'm currently editing — especially in large parametrized pytest files where it's easy to lose track of nesting.

The GitHub Workflow Habit That Pairs With This

Fast in-editor navigation is only half the picture. The other half is staying oriented across branches and commits. If you're working on a team — even part-time — having a clean consistent git branching habit means you spend less time untangling merge conflicts and more time actually writing tests. The keyboard shortcuts above keep you fast inside a file; a disciplined branch strategy keeps you fast across a sprint.

Common mistake: Testers who are new to VS Code often use the Explorer sidebar as their primary navigation tool. The sidebar is fine for an overview, but it's slow for jumping between files you already know exist. Train yourself to reach for Ctrl+P first. Within a week it becomes automatic.

Daily Workflow Habits That Compound Over a Week

Shortcuts are the micro-level. These are the habits — some with keybindings, some without — that operate at the session and day level. They're the ones that make a measurable difference when you look back at a week of work.

Run the Focused Test, Not the Whole Suite

The single most time-consuming habit I see in testers is running the full suite every time they want to check one scenario. In pytest, pytest path/to/test_file.py::test_function_name runs exactly one test. In Behave, behave --name "your scenario name" or behave features/your_file.feature does the same. Map a VS Code task or terminal alias to the pattern you use most. The feedback loop difference between running one test and running five hundred is enormous when you're in a debugging cycle.

Use the VS Code Test Explorer, But Know Its Limits

The Test Explorer panel (the flask icon in the Activity Bar) gives you a visual list of all discovered pytest tests with pass/fail status. It's useful for a quick overview. But for rapid iteration, the integrated terminal with a targeted pytest command is still faster — you see the full output, you can scroll the traceback, and you're not waiting for the UI to refresh. Use the Test Explorer to orient yourself; use the terminal to iterate.

Keep a Scratch Terminal Open

I always have one terminal tab dedicated to throwaway commands: a quick curl to verify an endpoint is up, a Python one-liner to decode a JWT, a cat on a response fixture file. This keeps those exploratory checks from polluting the terminal where your test runner output lives. Ctrl+Shift+` to create it, give it a name by right-clicking the tab. Costs ten seconds to set up, saves minutes of scrolling through mixed output.

Snippets for Boilerplate You Type Every Day

VS Code user snippets (Ctrl+Shift+P → "Configure User Snippets") let you define shorthand for patterns you type constantly. In API test work, that means things like a new pytest test function skeleton, a standard requests.get() call with assertion scaffolding, or a Behave step decorator. Here's a minimal example of a snippet for a pytest test function:

"pytest test function": {
  "prefix": "pytestfn",
  "body": [
    "def test_${1:name}():",
    "    # Arrange",
    "    ${2:}",
    "    # Act",
    "    response = ${3:}",
    "    # Assert",
    "    assert response.status_code == ${4:200}"
  ],
  "description": "Basic pytest test function with AAA structure"
}

Type pytestfn and hit Tab. The cursor jumps through each placeholder in order. This is the kind of habit that feels like a small convenience on day one and becomes something you miss the moment you work in a different editor.

The "Reopen Closed Editor" Reflex: Ctrl+Shift+T

Same as in a browser — reopens the last closed editor tab. I use this more than I'd like to admit. You close a file to declutter, immediately need it again, and instead of hunting through Ctrl+P, one chord brings it back.

Commit Small, Commit Often — With a Keyboard-First Git Workflow

This one isn't a VS Code shortcut, but it's a productivity habit that pairs with everything above. Committing small, logical chunks of test work — one scenario implemented, one bug reproduced — means your git log is readable and your diffs are reviewable. The VS Code Source Control panel (Ctrl+Shift+G) lets you stage individual lines within a file, not just whole files. That's the habit that makes your commits meaningful rather than dumping an entire afternoon of changes into one message. As your test suite grows in complexity, this discipline becomes even more important — a point worth keeping in mind as you think about how your overall automation architecture scales.

Time-Box Your Debugging Sessions

Not a shortcut, but a real time-saver: if a test is failing and you've been staring at it for more than twenty minutes without a clear hypothesis, write down what you've ruled out and take a break or ask for a second set of eyes. I've seen testers lose an hour to a failure that turned out to be a missing environment variable — something that a fresh look catches in thirty seconds. The keyboard habits above keep you moving fast when you know what you're doing. The time-box habit keeps you from burning time when you don't. Both matter for building the kind of well-rounded workflow described in resources like mapping your growth as an automation engineer.

The compounding effect: None of these habits is dramatic on its own. But a tester who uses Quick Open instead of the sidebar, runs focused tests instead of the full suite, and commits small throughout the day will move noticeably faster than one who doesn't — not because of raw typing speed, but because of reduced friction and shorter feedback loops. That's the real value of making these things automatic.