It seems to me you need to research unit testing before you go any further.
What I mean is...instead of writing external tests, you actually write the tests as members of an object (stripped in production code) this way, you could also test private and protected members as well
Unit Testing deliberately focuses on public methods and members. The reason is quite simple - you are not testing code, you are testing behaviour. You have a class which you expect to perform a specific task in a specific way using a specific API. Unit Tests allows you to test these concepts to ensure the behaviour you want is present - otherwise a test will fail signalling something is wrong.
Now since private and protected methods are only accessible within the parent class (and optionally a descendant) by testing the public methods you are also testing the private methods - the publics use the privates to give rise to the final behaviour. This is one reason why unit testing immediately puts a focus on refactoring - the better you're capable of refactoring, the better you can decompose public behaviour into focused public methods and private methods which are easily identified as being responsible for failed tests. For many test infected folk, a testable class is a good class (it means the class has followed at least some OOP best practices).
Does that make sense?
If you test individual private members you are simply duplicating test coverage and making far more work for yourself. Tests do not need to cover every minute implementation detail (who cares if you use a giant public method, or two dozen privates? The tests don't). That path will force you to update tests for every little refactoring. Unit tests shouldn't need updating. If you change the behaviour of classes, that's your doing - the unit tests are completely innocent of blame. If a bug still manages to creep in, guess what? Not the unit tests fault - *you* missed part of the behaviour when writing tests - see Regression Testing for this one.
Your objects ctor and dtor act as the setup and teardown functions...and this way...you avoid the worst part of writing unit tests...keeping your tests synchronized with the actual API...when I design...and first implement everything is extremely volatile...I change like lighting...keeping Agile so to speak
I came across this concept in the Zend Framework (a lot of developers have never practised TDD and it shows in spades) and its been infuriating at times at how poor some unit tests can be (minimal coverage, no exception tests, little realisation that unit tests are valid documentation). Unit Tests as a testing tool is the core purpose for their existence but there is so much more to unit testing. If you follow Agile practices, than Unit Tests are *never* written after the code - you always write the Unit Test *first*, then you write code to pass that test. Essentially, you never ever synchronise tests to your API - you actually synchronise your API to your newly updated tests

. The practice is Test Driven Design. By writing the tests first you ensure classes are testable - i.e. you are forced to refactor early and often, and reduce coupling to a minimum from the start. Arguably (I am strongly pro TDD but not everyone is

) this saves time in the long run, but costs more time at the start writing tests.
Admittedly I have a serious test infection...

. When I started with the ZF 0.20 the first place I went to was the tests directory. Why read the source code when the API is laid out in detail as part of the unit tests???
A few other points.
Unit Tests do not *force* good practice, they strongly encourage them assuming you can recognise the signals (code smells) and know how to refactor. TDD is not a standalone skill - without refactoring it will ultimately fail as a testing strategy. An example is using Singletons in constructors. If you do not use a Registry, or do not pass Singletons as parameters, then testing the class will prove difficult. This often requires finnicky workarounds like extending test classes, or adding conditional constructor arguments. The extra test work is not the unit testing being difficult, it's the developer not recognising the design problems with their supposedly independent decoupled class.
Same goes for using statics in classes - it makes testing difficult without pulling in the static's parent class (which may or may not be unit tested separately).
Unit Tests require little forethought. You plan the class, sketch a preliminary interface, write the unit tests which capture the planned behaviour. Write the code, then assess for refactoring possibilities. It's a simple, incremental process - once you accept the upfront time spent on writing tests and keeping your code passing green.
Since it's Saturday and I'm incredibly tired (late night) forgive any duplication of comments...
