Subj : Re: tools to build design of application
To   : comp.programming
From : Phlip
Date : Fri Jul 29 2005 10:06 pm

Roman Mashak wrote:

> How is this technique of running tests generally called?

Test Driven Development.

> And waht are tests
> suppose to test in units, like passing parameters, types or return values
> etc. ?

This is going to sound very difficult. You write each test and get it to
fail, then write _one_line_ of code, and make it pass.

(Long term, it's not strictly "one line", but you'l get the hang of that
soon.)

It sounds difficult when you can't imagine a test case reaching all the way
into code and detecting that line. Such code is "coupled", meaning you can't
re-use it without its contexts.

At their heart, all tests inspect Input Processing Output. If you put this
data In, and that data comes Out, then the Processing part must be
such-and-so.

So if you write all code by writing such test cases, they force code to
decouple, and that makes it better designed and more flexible.

Here are about 14 test cases, stacked for convenience into two test case
functions:

TEST_(TestCase, term)
{
    CPPUNIT_ASSERT_CLOSE( 3.0, parse("3") );
    CPPUNIT_ASSERT_CLOSE( 2.0, parse("2") );
    CPPUNIT_ASSERT_CLOSE( 2.8, parse("2.8") );
    CPPUNIT_ASSERT_CLOSE( 2.8, parse("  2.8") );
    CPPUNIT_ASSERT_CLOSE(-2.8, parse("-2.8") );
    ASSERT_BEEF( parse(".q")   , "syntax error" );
    ASSERT_BEEF( parse("- 1.0"), "syntax error" );
}


TEST_(TestCase, sum)
{
    CPPUNIT_ASSERT_CLOSE( 5.0, parse("3 + 2") );
    CPPUNIT_ASSERT_CLOSE( 1.0, parse("3 + -2") );
    CPPUNIT_ASSERT_CLOSE(11.0, parse("3 + 8") );
    CPPUNIT_ASSERT_CLOSE(11.0, parse("3 + 4 + 4") );
    CPPUNIT_ASSERT_CLOSE( 5.0, parse("-3 + 4 + 4") );
    ASSERT_BEEF( parse("3 + .q")  , "syntax error" );
    ASSERT_BEEF( parse("3 + 12 +"), "syntax error" );
}

That's from http://www.xpsd.org/cgi-bin/wiki?RecursiveDescentParserCpp

The macro TEST_() automatically runs the case at test time. You don't need
to call the test from anywhere; you just write it.

A test calls a target function like parse("3 + 8"), and returns 11.0. Input,
processing, output.

Of course writing all of 3 + 8 all at once is hard. The relation between the
test and the line of code it influences is hard to see.

But testing parse("3") is easy. All I needed to do was put strtod inside
parse(). So that was the test I wrote first.

When a project grows like this, tests cohere closely to the code, and the
relationship between a new test case and the next line of code it influences
is very obvious.

Richard Heathfield wrote:

> He's the TDD evangelist, not me.

Please. We prefer the term "pusher". The first hit is free!

> He has gained my interest. If he wishes to
> keep that interest, he will no doubt be prepared to go the extra mile and
> provide the information in a format that is palatable to start with. And
if
> not, well, it's no skin off my nose. TDD isn't /that/ interesting. :-)

http://www.newsgroops.org/group/comp.programming/article-274165.html

-- 
  Phlip
  http://www.c2.com/cgi/wiki?ZeekLand

.