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

Reply via email to