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

AggregateMethod()
{
  BaseMethodA()
  BaseMethodB()
  BaseMethodC()
}

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:

* Noting that your "aggregate method" looks mightily like the template method in TemplateMethodPattern, subclass the class containing the aggregate, have the subclass expect (in the syle of, or maybe even using a MockObject) the base method calls. 

* If you are allergic to inheritance, extract a MethodObject that takes an object supporting an interface that declares the base methods and calls A(),B(),C() on it. Mock that interface to expect the sequence, have the original class implement that interface also and pass an instance of itself to the method object.

* (I haven't actually tried this yet, caveat lector) use AspectOrientedProgramming to collect calls to A(), B(), C(). Someone said that AOP adds the power of a debugger to your code, seems as if testing is a place where that might be very useful

* ...

----

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:

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

--Phlip

----
CategoryTesting