"The other thing I would suggest is to experiment with
lisp to see why TDD in that context is as usefull as
a chocolate hammer :-).
Honestly, asking lispers to embrace TDD is like taking
a bicycle to a ferrari factory to demonstrate this
wonderful invention of the wheel with inflated
tyres - they already know about your wheel and they
find it laughable. "
For the full discussion see comp.programming
http://groups.google.com/group/comp.programming/browse_frm/thread/4137bad47ff4026f/4037af289c3dc9f3#4037af289c3dc9f3
In comp.lang.lisp wooks <······@hotmail.com> wrote:
> Honestly, asking lispers to embrace TDD is like taking
> a bicycle to a ferrari factory to demonstrate this
Calling a function in the REPL to see if it returns what you want
isn't TDD.
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
Stefan Scholl wrote:
> wooks wrote:
>> Honestly, asking lispers to embrace TDD is like taking
>> a bicycle to a ferrari factory to demonstrate this
>
> Calling a function in the REPL to see if it returns what you want
> isn't TDD.
However, wooks correctly recognizes that one major benefit of TDD is a
reactive environment. You can perform little experiments and immediately
check results, isolated from the rest of your application.
The distinction is TDD preserves a record of these experiments.
Here's a summary of the TDD mailing list Lisp thread:
Adrian Howard wrote:
> > goose wrote:
> >> I /still/ consider TDD moot in a lisp environment,
> >> and I would *really* like to hear an experienced
> >> lisper tell me how to make TDD useful in a lisp
> >> environment[1].
> >>
> >> Unless the code of the test itself is complex
> >> (more than a few lines), why would I write the
> >> test:
> >>
> >> (foo 1 2 3 "Hello")
> >>
> >> before writing the function foo? I'd just have to
> >> retype it (or re-evaluate it) /after/ writing the
> >> function so why not skip the first time.
> >>
> >> With more conventional languages (Java, C++, etc)
> >> you will have to write it into a source file
> >> no matter how small it is, so it makes sense
> >> to write the test first.
> >>
> >> With lisp, the source file is optional.
> Well - it's been more than ten years since I've done any serious Lisp
> (love the language, nobody will hire me to write in it though :-) but
> I'd say it's just as valid as in any other language.
>
> You need to write it before hand so that you have something to judge
> "writing the minimal amount of code to pass the test".
>
> Sure if you have the raw will power to imagine the test you will
> write, only write the code necessary for your imaginary test, and
> then write the test afterwards you'd get the same result - but I
> personally doubt that can be done successfully.
>
> I don't follow why the argument is any different for image based
> rather than file based environments.
>
> (BTW there's a nice bit on building a test framework with Lisp macros
> in chapter 9 of Practical Common Lisp <http://www.gigamonkeys.com/
> book/practical-building-a-unit-test-framework.html> ;-)
Ron Jeffries wrote:
> People who program in languages like LISP, not just like Java / C#,
> say that TDD, once they got good at it, has become an important part
> of their software development repertoire, and has changed the way
> they think for the better.
>
> Most of them also report that they did not expect this result, but
> decided to learn TDD anyway, based on what people they respected had
> told them. It's not hard to learn, though it does take some
> thought and practice.
>
> There's no guarantee, but I would suggest that the experience of
> senior people who have tried this thing may make it worth while to
> learn TDD before deciding whether it's valuable or not.
>
> I myself do not use LISP any more, so I can't comment directly. I
> have used TDD, however, in Java, C#, Smalltalk, and Ruby, and were I
> to go back to doing LISP, I'd certainly use TDD, with the
> expectation that it would help me there, as it does in all the other
> languages I work with.
>
> Ron Jeffries
> www.XProgramming.com
> Design is the thinking one does before, during, and after
> implementation. It works best for me with a little up front, most of
> it during implementation, and very little after it's too late.
Anderson, Kelly wrote:
> I'd try the double entry bookkeeping analogy on them. If you are an
> accountant, do you give up double entry bookkeeping just because you
> moved from PeachTree Accounting to Quicken?
Kelly refers to Pacioli Double Entry Accounting notation.
http://en.wikipedia.org/wiki/Double_entry_bookkeeping
You add up all assets in one column, and all debits in another column. You
never subtract, and you keep the two columns balanced.
This is a close working metaphor of TDD, for two reasons.
One reason is you write tests (debits, or negative questions) in one column,
and constantly match them to production code (credits, or positive answers)
in another column.
Another reason is its applicability. Double-entry Bookkeeping really _is_ an
example of "one size fits all". Some technologies are not for everyone, and
some really _are_ for everyone. Double-entry Bookkeeping even survived the
invention of the computer, which dethroned many other notation techniques.
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
> The distinction is TDD preserves a record of these experiments.
If you type the test expression in the source file, and then evaluate
it as needed (every time you change the function it tests for example)
this preserves the tests too. The difference is that with TDD you
evaluate all tests.
···········@gmail.com writes:
>> The distinction is TDD preserves a record of these experiments.
At a high cost.
Typing at the REPL vs. typing in a test file, with the collection of
the expected result, in the good format for the test driver, it's
about two or three times the work.
Perhaps we could have an IDE watch what we do at the REPL and extract
the test cases and good results from there automatically...
In any case, sometimes you have to invest the cost of testing...
> If you type the test expression in the source file, and then evaluate
> it as needed (every time you change the function it tests for example)
> this preserves the tests too. The difference is that with TDD you
> evaluate all tests.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
Gerry Quinn wrote:
>> I think the vibe is a few years ago they were adopting, and nowadays
>> they are adopted, and not shy about it.
>
> All the "vibe" is from propagandists/consultants who may be expected to
> exaggerate the role of their partyicular brand of snake oil.
You are just irritated that I answered your question so affirmatively.
To goose: TDD _is_ XP. XP is tests driving development, at all scales.
> You have a link to evidence of MS adopting TDD?
http://www.google.com/search?q=%22test+driven+development%22+site%3Amicrosoft%2Ecom
623 hits. (Google for ["test driven development" site:microsoft.com].)
I think Ward Cunningham, one of TDD's inventors, worked there for a while
coaching their processes.
And note especially this page:
http://msdn2.microsoft.com/en-us/library/ms182521.aspx
It's nothing but a blurb that topic 182521 has been retired. That page
formerly contained a damagingly innaccurate version of TDD. The community
complained, and MS since fixed the issue with a more accurate page.
Somewhere.
Pascal Bourguignon wrote:
>>> The distinction is TDD preserves a record of these experiments.
>
> At a high cost.
At a low cost. Each experiment should be easy to write, because it should
reuse whatever fixtures supported the last test cases in this area.
Further cost savings come from not needing to debug. Everyone who has tried
TDD (except goose, and Mike Bolton) have reported they go much faster.
> Typing at the REPL vs. typing in a test file, with the collection of
> the expected result, in the good format for the test driver, it's
> about two or three times the work.
A test case (admittedly written in an inferior language):
TEST (StreamingTextCopiesCharacters)
{
MemoryOutStream stream;
stream << "Lalala";
CHECK_EQUAL ("Lalala", stream.GetText());
}
And another one:
TEST (StreamingMultipleTimesConcatenatesResult)
{
MemoryOutStream stream;
stream << "Bork" << "Foo" << "Bar";
CHECK_EQUAL ("BorkFooBar", stream.GetText());
}
Note that it looks very similar to the first one. Someone more suspicious
that me might think the programmer simply copied the first one and modified
it slightly to produce the second one. (The tested feature is operator<<
chaining.)
If you claim that Lisp makes this hard because it makes writing functions
and preserving them, as text, hard, then this might be a problem with Lisp.
But the Lispers who use TDD have not reported this problem.
Clone-and-Modify-Programming is evil, so let's make test cases easier to
re-use:
struct DeferredTestReporterFixture
{
...
};
TEST_FIXTURE(DeferredTestReporterFixture,
ReportTestStartCreatesANewDeferredTest)
{
reporter.ReportTestStart(details);
CHECK_EQUAL(1, (int)reporter.GetResults().size());
}
TEST_FIXTURE(DeferredTestReporterFixture,
ReportTestStartCapturesTestNameAndSuite)
{
reporter.ReportTestStart(details);
DeferredTestResult const& result = reporter.GetResults().at(0);
CHECK_EQUAL(testName.c_str(), result.testName);
CHECK_EQUAL(testSuite.c_str(), result.suiteName);
}
Many more test cases re-use the DeferredTestReporterFixture. It supplies the
variables and functions that a whole suite of test cases will re-use.
> Perhaps we could have an IDE watch what we do at the REPL and extract
> the test cases and good results from there automatically...
I have heard this is how Smalltalk grew SUnit; as a
library/image/editor-extension thingey.
> In any case, sometimes you have to invest the cost of testing...
Prevention is better than a cure.
> "Remember, Information is not knowledge; Knowledge is not Wisdom;
> Wisdom is not truth; Truth is not beauty; Beauty is not love;
> Love is not music; Music is the best." -- Frank Zappa
Way!
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Le Fri, 18 Aug 2006 16:00:41 +0000, Phlip a écrit :
> To goose: TDD _is_ XP. XP is tests driving development, at all scales.
Why the need for yet another name?
>> You have a link to evidence of MS adopting TDD?
> http://www.google.com/search?q=%22test+driven+development%22+site%3Amicrosoft%2Ecom
That's no evidence of anyhting but that MS gives information on how to
use TDD...
> And note especially this page:
> http://msdn2.microsoft.com/en-us/library/ms182521.aspx
Which says:
``Guidelines for Test-Driven Development
This topic is obsolete and has been removed from the MSDN
documentation.''
So far so good. MS tried TDD, and they say it's obsolete. ;-)
> It's nothing but a blurb that topic 182521 has been retired. That page
> formerly contained a damagingly innaccurate version of TDD. The
> community complained, and MS since fixed the issue with a more
> accurate page. Somewhere.
Or nowhere. Any URI?
> Further cost savings come from not needing to debug. Everyone who has
> tried TDD (except goose, and Mike Bolton) have reported they go much
> faster.
For the sake of my curiosity, is this your personal experience or a fact
based on a study made with controlled methods?
Curiously,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
> Phlip a ecrit :
>> To goose: TDD _is_ XP. XP is tests driving development, at all scales.
>
> Why the need for yet another name?
Because calling it "eXtreme Programming" was a mistake, and a trick to hook
the early-adopters. Calling it what it actually is - using tests to drive
development - is a lot more progressive.
MS's official policy is its individual teams select their methodologies,
from an approved list. XP - hence TDD - has been on that list for several
years now, and some teams use it. One of their members wrote this:
> TDD pays for itself twice, in my experience
> once when the code is being written (better interfaces, fewer defects
> and simpler code) and once when the code is being maintained (far
> less time spent regression testing)
> The first is about quality. The second is about adaptability.
> If your team is not well practiced at code inspection, TDD acts as your
> code inspector, validating the functionality that you intend. It doesn't
> validate that the code meets the spec, usually. It does validate that the
> code meets the developers desired results, since the developer has to
> enter the desired results in code. This forces the developer to focus on
> what they really want to see.
> --- Nick Malik [Microsoft]
So go ahead and snip any evidence that disagrees with your point... what
ever it is!
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!