back




April 2017

I think it's far more important to test a program fast than most people realize. Testing fast doesn't just verify answers; it generates them. If you're bad at testing fast and don't like to do it, you'll miss out on most of the new directions to take a program that testing fast would have generated.

As for how to test fast, 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; 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; 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]; have expected results for each testcase in a separate file and have the testcase output diffed against it; automatically generate testcases 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; keep testing if it keeps producing results; invest time to develop muscle memory for using shortcuts fast; if you hear a rhythmic pattern and it feels like all you're doing is typing shortcuts instead of programming you're all set.









Notes:

[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 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+Option+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); learn to remove a window (C-x 0) or keep it (C-x 1); learn to 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 automatically complete or generate code, 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 the rest of the system requires a mouse, learn to use the mouse with the left hand because the arrow keys tire the right hand.