Test Driven Development For Aggregate Methods

How does one write a ProgrammerTest for an aggregate method? For example, say I have the following:

AggregateMethod?() {

It is straight forward to write the tests for BaseMethodA() ... BaseMethodC(). How should I write the test for AggregateMethod?() without repeating the lower level tests?

The approach I have been using so far is to just write the test for AggregateMethod?(), but I end up with a lot of lower level test code segments that get repeated. Should I just write the lower level tests and assume that AggregateMethod?() is correct because it is based on tested methods? Do I write both higher and lower level tests and ignore the redundancy?

What are people doing in practice? Thanks. WayneMack

Some suggestions from KeithBraithwaite:

Here's a thread from the XpNewsGroup?:

CodeMonk? wrote:

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:




View edit of June 15, 2004 or FindPage with title or text search