| Good, but overly long article. I have reached the similar conclusions in favor of functional tests over the last decade or so. Personally, I have worked seriously used DBC, TDD, and automated scenario testing, and hybrids in that order of learning. My conclusions about the sweet-spot (and this may vary depending on your area): 1. Automated functional testing in the large, and DBC in the small is a winning combo. 2. Special techniques for graphics intensive programming: I get my scenario tests to show what's happening on the screen, and I can slow 'em down and step through 'em 3. I never got a lot of dependency injection / mocks (like the author) -- not sure if I don't get 'em or application area is wrong 4. You need special techniques for intensive algorithmic code where there's a combinatorial explosion of cases and line coverage won't do; e.g. randomly generated test cases + compute intensive sanity checks Bottom-line: Automated scenario tests exercise the code; DBC pin-points illegal states. DBC = Design by Contract = pre-conditions + post-conditions + invariants. In practice understanding the method (this takes work) and writing explicit pre-conditions gives ~70-80% of the benefit. To do invariants well needs language support. |