April 2017, rev. November 2019
I think it's far more important to test a program well than most people realize. Testing doesn't just verify answers; it generates them. If you're bad at testing and don't like to do it, you'll miss out on most of the directions to take a program that testing would have generated.
As for how to test well, here's one version: Don't use the mouse; setup the window manager so that pressing Alt-Tab switches from the text editor to the terminal and with no switch delay; have a testsuite; test the small thing before testing the bigger thing; make testcases executable on the command-line; pick one testcase to call and type the command that calls it on the command-line; press Alt-Tab to switch back to the text editor and add printfs; use printfs not the debugger because printfs build a log and some types of problems can be debugged only with a log; press Alt-Tab to go back to the terminal, then press the up arrow key and Enter to call the testcase again; only use a shell that prepares the last command when you press the up arrow key, or use a repl; write scripts that setup a clean slate and make this setup fast; add these scripts in the testsuite so testcases can call them if needed; setup virtual desktops in a 2x3 or 3x3 but not in a row ; open new terminals as tabs in the same terminal window with Ctrl+Shift+t (or in a new terminal window with Ctrl+Shift+n for other tasks, eg for psql to many dbs); switch between terminals with Ctrl+PageUp and Ctrl+PageDown to compare a candidate change across more than one testcase; close unused terminals with Ctrl+d; have expected results for each testcase in a separate file and have the testcase output diffed against it; generate testcases automatically if possible; add a one character alias in .bashrc to diff the working copy of the source code, add another that shows the current branch; make most shortcuts run in less than 50ms; commit as soon as something's fixed; it's ok to try small changes instead of think hard; learn to distinguish you being exhausted from the problem being hard; it's ok to fix small stuff when tired; keep testing if it keeps producing results; invest time to develop muscle memory for using shortcuts fast; if you hear a pattern and it feels like all you're doing is typing shortcuts instead of programming you're all set (a shortcut is to a programmer's mind what an index is to a database.)