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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to