I think that something is being missed on this thread. An earlier poster pointed out that private methods should not be tested. I agree with that. After all, any private method should be present in support of a public method of some kind. Therefore test the public interface of your class only and all other private methods that are invoked by this public method will be touched by the unit test accordingly. By making tests too aware of the internals of your class you can end up with very brittle tests. Having to modify a unit test just because the internals of the class changed is not good.
Paul --- Brian - IT Department <[EMAIL PROTECTED]> wrote: > > How do I write tests for internal and private methods and classes? > One way is to make a public class that inherits from the class with > private and internal methods and make public methods with identical > signatures (using the 'new' keyword) for the internal and private methods. > This class should be conditionally compiled out of the release build and > in a test namespace, though. > > > How do I control the order of the various tests? > All tests must be order independant. > > > How do I control the environment (start and stop applications that the > > code being tested is supposed to communicate with)? > Looked at the setup and teardown attributes. Maybe look into mock objects > to simulate the environment. > > > Do you know any good articles I should read (that goes beyond the scope of > > getting started)? > Based on your questions, I think you need to read articles on the scope of > getting started first. Buy a book like "working effectively with legacy > code" or "test-driven development". > > -- Brian > > =================================== > This list is hosted by DevelopMentor® http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
