Maybe I'm reading the wrong programs, but I haven't seen any unit tests that were an adequate replacement for either comments or out-of-band documentation. For

Maybe I'm reading the wrong programs, but I haven't seen any unit tests that were an adequate replacement for either comments or out-of-band documentation. For example, I looked up the SQLite source (which often comes up here as an example of a well-written program), picked the first source file I saw (alter.c), and one of the first comments is this: /* The principle used to locate the table name in the CREATE TRIGGER ** statement is that the table name is the first token that is immediatedly ** preceded by either TK_ON or TK_DOT and immediatedly followed by one ** of TK_WHEN, TK_BEGIN or TK_FOR. Another great one: ** Note that ON cannot be a database, table or column name, so ** there is no need to worry about syntax like ** "CREATE TRIGGER ... ON ON.ON BEGIN ..." etc. What unit test would you write to convey this information? Tests can be helpful but they serve a completely different purpose. You can of course write a test to cover the same ground as these comments (and knowing SQLite, they probably did), but a unit test to poke at corner cases is nowhere near as clear as simply stating what's going on. I think the article means to suggest that one possible way to nudge programmers to keep comments up-to-date is to have editors that don't make them appear "washed out".