Re: TDD doesn't suck

goose wrote:

How am I misinterpreting it? The "OTOH" means
"On the other hand" so it would mean that TDD does /not/
require you to brute force test. Sorry if that wasn't
clear.

Sorry; I overreacted to "brute-force". We might be nearing alignment. Here's
why I overreacted:

The tests are simple but not brute-force. Let's reserve "brute-force" to
mean "stepping through every combination, in order". The worst kind of
algorithm. TDD test cases are "design constraints"; they are not about the
same things as Unit Tests are about.

One myth of TDD is "write a test case that fails in such a way that only the
correct code can pass it". That's wrong, but some TDD tutorials talk like
that.

Here's some TDD:

TEST(CheckSucceedsOnTrue)
{
bool failure = true;
{
RecordingReporter reporter;
UnitTest::TestResults testResults_(&reporter);
CHECK (true);
failure = (testResults_.GetFailureCount() > 0);
}

CHECK (!failure);
}

That's from UnitTest++. It checks that the CHECK(macro); increments the
FailureCount value. The testResults_ thing is a copy of the infrastructure
that the TEST() macro itself uses. This is one of the test cases used to
build UnitTest++ itself.

Note that it doesn't even check the resulting count is 1. It could. But it's
not a Unit Test, and it doesn't even pretend to provide coverage.

None of the test cases are any more complex than that. Some have more lines,
but none have more logic.

You would find adding a bug to UnitTest++'s core, then passing all the
tests, very hard.

Maybe I do have the wrong end of the stick wrt TDD,
please, by all means clear up my misconceptions.
1. Write a minimal test for proposed functionality.
2. Do a minimal number of edits to make the test fail
for the correct reasons.
<compile>

compile and test.

3. Implement enough of the functionality to make the
test pass, undoing any edits on errors.
<compile>
4. Refactor and neaten if need be.
5. Lather, Rinse and Repeat.

Okay, I'll calm down now.

I hope that I at least got the basic gist of it, if not
all of the finer detail. Now, compare that with my
typical lisp cycle:
1. Write the function (say .. "foo").
2. If, while writing the function, I decide that
non-existent functionality is needed and therefore
a new function is needed (say ... "bar"), I go ahead
and write a call to the new function.
3. I evaluate foo and get an error (bar not written yet)
so I go back to step 1 writing bar or get an error
(a bug) which will then get attention.
4. Once foo evals cleanly, I try a few more evals
and then move on, back at step 1 for the next
piece of functionality.

The big difference between the two seems to be that
TDD is test-first and I do write-first.

The other big difference is nothing stops you. The goal is the ability to
write Foo(), now, and ignore Bar(), written long ago. The more you can
ignore, the faster you go. But writing Foo() might require changing code
that Bar() depends on. Without test suites, Bar() might get a quiet bug.
Worse, Bar() might get wedged so _another_ change would make it express a
bug. In that situation, Foo() is not implicated, and you must debug Bar() to
seek the cause.

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.

I passed this question to the TDD mailing list. But you should trust your
own USENET proficiency enough to ask comp.lang.lisp. Not all TDD posts start
flamewars.

They used to start them all the time on news:comp.object , but they don't
seem to any more. For some strange reason...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


.

Relevant Pages

  • "reexporting" symbols
    ... (:export foo bar)) ... and package B which uses package A's symbols, ... But to take advantage of the full functionality of:b, ...
    (comp.lang.lisp)
  • Re: Code Coverage and QC
    ... I never add functionality until I have a failing test ... then the tests in TDD are Unit Tests ... I will also add that in TDD refactoring is constantly applied to try to ...
    (comp.object)
  • Re: Code Coverage and QC
    ... >pure hell to deal with thousands of issues on functional level that were ... I am curious, however, since we had all that discussion on coverage, ... What happens using TDD is that the "coverage" one gets is aimed and ... holes in functionality. ...
    (comp.object)
  • Re: "Document Elements", "Quick Tables", etc. Bar
    ... the "Document Elements | Quick Tables ..." ... functionality is worth something, and maybe a lot. ... This is even more annoying as all the monitor manufactorers seem to switch to the wide screen format, while Microsoft keeps adding new tool bars, leaving less and less room for the essential, namely the text. ... I think its official name is "Elements Bar" but I could be wrong. ...
    (microsoft.public.mac.office.word)
  • Re: Will Windows 7 be visually similar to Vista?
    ... learn the functionality of the new interfrace in comparison to ... implemented since Windows 95 through Windows XP that Vista is ... I do not like the Address Bar on top, ... I really do wish that the interface was more customizable. ...
    (microsoft.public.windows.vista.general)