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 [1]; 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.)


[1]  Using more than 3 virtual desktops in a row is confusing and takes too long to move from desktop 1 to desktop 4.

It took writing this to see a third of testing depends not just on the window manager and terminal being good but also the text editor being a window manager: Don't use multiple monitors because you must move the neck to use them; open a second window to look at a different piece of the code in the text editor (like M-x make-frame in Emacs) and place it in a different virtual desktop with Shift+Alt+Ctrl+up-arrow; don't open more than 3 windows with code from the same project; split windows when needed either vertically (C-x 3 in Emacs) or horizontally (C-x 2); remove a window (C-x 0) or keep it and remove the rest (C-x 1); switch to the previous file with a shortcut (C-x b); make it easy to undo (C-_) in multiple files; if you split a window into 4 pieces go back to 3; press Ctrl+Alt+up-arrow to switch to the second text-editor window.

While on the topic of text editing: No, don't use the mouse, search for text instead; don't use web-based text editors because they can't do all of this and are slow; don't use IDEs that complete or generate code automatically, use macros instead; organize source code so that switching in the text editor between the files is fast too; all code small enough to fit in a single file is best; drop qwerty.

If parts of the system require a mouse, learn to use the mouse with the left hand because the arrow keys tire the right hand.