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.
smime.p7s
Description: S/MIME cryptographic signature
