burla parcial como olor a código?

Question

¿Por qué hay tanto odio sobre 'burlas parciales' y el código que lo requiere?

Aquí es una implementación (teórico) ejemplo:

public ComplexResult1 operationA(Stimulus a) { 
    { 
     ... 
     result = ...; 
    } 
    auditTheChange(a); 
} 
public ComplexResult2 operationB(Stimulus b) { 
    { 
     ... 
     result = ...; 
    } 
    auditTheChange(b); 
    return result; 
} 
void auditTheChange(Stimulus stim) { 
    // do a bunch of stuff to record the change 
    // and interact with another outside service 
} 

Ahora, en mi entender esto es así refactorizado código.

Si deseo de probar la unidad OPERATIVO y operationB, y asegurar que la auditoría que sucede en cada escenario, pero sin tener que probar las características específicas del código de auditoría, me gustaría utilizar burla parcial.

¿Qué no estoy viendo/entendiendo que causa tantos proyectos (EasyMock, Mockito, etc.) para recomendar la refactorización?

Answer 1

Si la auditoría es realmente una función interna de la clase, entonces el código debe probarse como parte de la prueba de la unidad. ¿Por qué su clase maneja operaciones complejas y auditoría? ¿Se podría mover la auditoría a una clase separada?

En caso afirmativo, presente la auditoría como colaborador de esta clase y protéjala. Si no, prueba la unidad.

Puede usar simulaciones parciales, pero en este caso creo que es una indicación de que la clase está haciendo demasiado.