On Thu, 2011-12-22 at 15:35 -0500, Larry Johnson wrote: > > > On Thu, Dec 22, 2011 at 2:54 PM, daly <d...@axiom-developer.org> > wrote: > > > > > The combination of literate + TDD seems forbidding. > > > Are you finding it hard to explain why you wrote a test? > > Tim Daly > > > > I decided awhile back when trying to answer questions about literate > programming, that people get caught up in the moving parts, and not in > what the approach actually yields. Your statement above puts it > nicely and succinctly, and hearkens back to Knuths original articles. > Lately I emphasize the woven text (without inititially calling it > that)
Untangling woven text is trivial. It can be done in any language. See http://axiom-developer.org/axiom-website/litprog.html > and ask the person I'm talking with to imagine writing an article or > book about their code, how it works, with proofs where appropriate. > That article should be written as a work of literature. Not all > literature has to be Hugo or Melville (or Jack Kerouac, or Gertrude > Stein for that matter). Some programs are more appropriately Mickey > Spillane or Terry Pratchett, or even in the style of a manual for an > electric razor. The point is that it should be satisfying to read and > comprehensively informative. > > Test code, and descriptions of external libraries are no different > from any other sections of the article or book. The most important > thing is to introduce them into the work at point most conducive to > the reader's understanding. If a test is testing something worthwhile, as opposed to the "blindly testing that 3=3" mindset, then it probably only takes a couple lines to motivate why you need the test. A test paragraph could contain the details. So if you're writing a hash table implementation, the test code of overflow chaining could explain what problems might occur (e.g. what happens when the table is actually full? How do you detect that the overflow chain has looped?, etc.) So if you wrote the hash table implementation code in literate form then each test could explain (and test) a particular boundary case or issue that might arise. This has the effect of motivating tests that are detailed, based on real issues, and handle boundary cases clearly. > > I really believe that there's no programming or engineering > methodology which doesn't lend itself to literate programming. If it > can be described, it can be presented in the form of an article. If > it can't be describe in human language it's probably terrible code. Test cases don't have to appear as "test cases". They appear in the text as either example code (useful for the reader but also testing) or as explanations of possible failures, misuse, misapplication, or boundary cases. This is especially powerful if you focus your tests on precondition/postcondition testing. See Hoare's paper "An Axiomatic Basis for Computer Programming" http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.116.2392 Using Hoare's ideas to focus the development of your test cases means that your tests have a good theoretical basis. They check for the conditions that should survive refactoring. Requiring precondition postcondition tests, along with clearly written natural language explanations, could be part of the peer code review prior to accepting new or revised code into the main line. Better yet, in a literate program, you can explain what the invariant is, why it is important, and what breaks when you violate it. So testing now has a good formal basis rather than random 3=3 tests. We can be so much better programmers. Raise your game. Be literate. Tim Daly -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
