Extreme Programming - The Two Method Problem!

Author

The Two Method Problem!

CodeMonk

2004-06-10, 3:57 pm

Hello everyone,

I am tring out test-driven development with NUnit. I have a class with two
public functions: CreateFile and UploadFile.

Both of these functions use many smaller private methods that I would like
to test but NUnit will not let me test private methods and I don't want to
change there scope. I also hear that testing anything other then the public
methods shouldn't be done anyway.

Your advice? Should I just build the smaller functions without tests and
test the public functions when they are complete or is there another way to
Nirvana?

Enough for now,
CodeMonk

Phlip

2004-06-10, 3:57 pm

CodeMonk" <somewhere@nowhere.com> wrote in message
news:jJ0xc.13316$9g6.1439@nwrdny03.gnilink.net...

> Hello everyone,
>
> I am tring out test-driven development with NUnit. I have a class with two
> public functions: CreateFile and UploadFile.
>
> Both of these functions use many smaller private methods that I would like
> to test but NUnit will not let me test private methods and I don't want to
> change there scope. I also hear that testing anything other then the
public
> methods shouldn't be done anyway.
>
> Your advice? Should I just build the smaller functions without tests and
> test the public functions when they are complete or is there another way
to
> Nirvana?

Pull the class out of your project. Put it on your desktop to refer back to,
as a "cheat sheet".

Write a test that expects the class to exist, and exhibits its most basic
function. Maybe a zero-length file via CreateFile().

The assert will show a new file of a given name exists. (The tearDown()
method should nuke this file.)

Make the test compile: Provide a new class with the correct name, and an
empty implementation of CreateFile().

Make the test pass: Put a primeval implementation inside CreateFile().

Now write a new test for the next ability. Maybe the sample file now has one
little record in it. Make that test pass, and refactor the innards of your
class.

As you add abilities, your refactors will get simpler as you use Extract
Method to create new private methods in your class.

At the end, if you wrote tests for each ability, you will have no more or
less than a clean, minimal, and fully tested class implementation. All its
private methods are indirectly tested. You can check that by inserting
faults, and tests will break.

Try this write-up:

http://flea.sourceforge.net/TDD_in_a_nut_shell.pdf

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Sponsored Links