I wholeheartedly agree with the author where he talks about documentation. Documentation is presentation, and you present to different audiences. You will rep

I wholeheartedly agree with the author where he talks about documentation. Documentation is presentation, and you present to different audiences. You will repeat concepts. However, duplicate code is the greatest sin in software design. Almost every good practice or rule we have conjured is an attempt to reduce code duplication. Redemption comes in the form of abstraction. How could anyone defend duplicate code? The author mentioned two kinds of duplication in tests. The first is a case of "You're doing it wrong." Here is a good rule of thumb for tests: if you find yourself copy-pasting between the code you wrote and the test you write for that code, you are not testing the code. Find an alternative way to test it. You will find a lot more value in it. The second is a discussion of setup and teardown being repeated. You are writing a lot of extra noise. Perl's Test::Class, for example, allows you to write one setup and teardown for all the tests in a Test::Class child. Reduce copy-paste by grouping together classes of tests. Even without a nice test framework, setup and teardown are trivial to implement yourself. Don't write tests that are a series of lines in one large main function. Sometimes you can factor out this duplication. However, in less dynamic languages like C, it may not always be easy to do so. What does this "less dynamic" mean? The example is easy to refactor into a function for both: stuff(1); call_something_unrelated(); stuff(2); C can abstract. It is not as good at abstracting as Lisp (what language is?), but there are solutions for most situations. Don't ever accept the idea that code duplication is legitimate.