On Thu, 3 Feb 2005, Barry Sperling wrote:

>
>
> Hugh Sasse Staff Elec Eng wrote:
>
>> Which bit is confusing you? The test unit bit,
> Yes.
> 	1) I am not clear on whether only the classes are being tested ( no 
> instances, no run with real inputs ) or a full program can be tested.

Usually, when one does unit testing, the unit is a class. This is
just the conceptual grouping you use. Conceivably you could use any
group in a testing class, but Unit Testing is not considered the
same as system testing.

The actual tests may test class methods, which don't require an
instance, but in most cases (when you look at tests people in
general write [Warning: generalization! :-)]) you will find that they
create an instance to test.

You may test with real data, but not live -- changing -- data,
because you need to be able to repeat the tests to be sure your fix
didn't break anything, etc.

> 	2) Is the intent to test all boundary conditions?  Pre-conditions? 
> Post-conditions?

Essentially, all of those.  How exhaustive you maek it is up to you.
In the test first model of programming, (such as XP -- eXtreme
Programming, rather than the Microsoft product of that name!) your
tests are essentially your definition of that the unit (class)
should do.  You write code until all the tests pass.  Then you don't
add any more (because YAGNI "You Ain't Gonna Need It" -- its not in
the spec and requirements change.)

> 	3) Is a single test meant for a single class and its subclasses, or

A testing class usually tests one class.  The methods (of the
TestingClass) with their assertions test some functionality of the
class.  You ideally write them to test the interface only, so that
when you change the internals later you can run the same tests to be
sure the code still works.

> does it work just as well with all of the classes that might be in the

Testing all the classes in one TestingClass would be too much.  That
is more of a system test.  You usually write one TestingClass per
class.  This is all about modularity, and ability to change things.
Also, the idea in OO is to think at the object level, so you make
sure each object works correctly to be confident they will work
correctly when connectd together.   Of course, your program may be
an object, so you test its interface, but when doing that you don't
test the internals, because they may be subject to change.

> program at once?
> 	Thanks,
> 		Barry
>

Hope that helps.  Maybe soeeone else will add more, or correct this
if I've missed something.

         Hugh