Le 23 avr. 2014 à 22:25, Attila Magyar a écrit :
Christophe Demarey wrote
... but sometimes, even in a well-designed class, you may need to test a very small part of this class, and in this case, you need a real object with some mocked methods.
I assume that there is a method need to be tested, but it calls towards an other either public or private method of the same object. And you'd like to mock that second method. Am I understanding correctly?
right
Why can't just allow the first method to call the second one? Is it slow, complicated to setup or requires some external resource to execute? Does it help to extract the logic from the second method to an other object? Without a concrete example, I'm just speculating.
My point here is just to test a method in isolation. If MyClass>>methodA calls MyClass>>methodB and there is an error in MyClass>>methodB, I don't want to have the test on methodA failing but just the test on MethodB. With "cascade testing", you will get a lot of failing tests and you need to investigate to find the culprit. As you said, if the class is well designed, it is not a big trade-off to unit test a small set of methods if they are short and related but I have the feeling that it would be good to be able to do that in some cases.