On 27-Sep-10 15:07, Modulok wrote:
In an ideal world, I agree. This is possible for pure functional programming where state is avoided. However, when dealing with object oriented, imperative programming, state changes cannot be avoided.
Generally, a unit test should test a single aspect of a single unit of your program. This is used all the time in object oriented programming. You set up an object (or collection of them), set up an initial state, test the behavior, and tear it down again. The state should not affect the assumptions of any other unit test.
Thus if a method requires an object be passed to it, I'd like to verify that object is being constructed correctly by the object factory, before verifying that the method which uses said object, is correct.
No problem. The object's constructor will have a number of unit tests of its own to ensure objects are constructed correctly, and the method has unit tests for them which test various cases about their behavior, etc.
I suggest picking up a good book or two about unit testing so you get off to the right foot about how this is usually done. I'm not sure you're seeing the complete point of this.
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
