Generalmente prefiero usar simulaciones debido a las expectativas. Cuando llama a un método en un stub que devuelve un valor, por lo general solo le devuelve un valor. Pero cuando llamas a un método en un simulacro, no solo devuelve un valor, sino que también impone la expectativa de que configuraste que incluso se llamó al método en primer lugar. En otras palabras, si configura una expectativa y luego no llama a ese método, se genera una excepción. Cuando establece una expectativa, básicamente está diciendo "Si este método no se llama, algo salió mal". Y lo opuesto es cierto, si llamas a un método en un simulacro y no estableces una expectativa, emitirá una excepción, básicamente diciendo "Oye, ¿qué haces llamando a este método cuando no lo esperabas?".
A veces no desea expectativas en cada método que está llamando, por lo que algunos frameworks burlones permitirán burlas "parciales" que son como híbridos simulados, ya que solo se cumplen las expectativas que establezca, y cualquier otro La llamada a método se trata más como un apéndice porque solo devuelve un valor.
Sin embargo, un lugar válido para usar talones que puedo pensar en la parte superior es cuando se introducen las pruebas en el código heredado. A veces es más fácil crear un apéndice subclasificando la clase que estás probando que refacturando todo para hacer que la burla sea fácil o incluso posible.
Y a esto ...
Evite usar simulaciones siempre porque hacen que las pruebas sean frágiles. Sus pruebas ahora tienen un conocimiento complejo de los métodos llamados por la implementación, si la interfaz simulada cambia ... sus pruebas se rompen. Así que use su mejor juicio ... <
... Digo que si mi interfaz cambia, mis pruebas se rompen mejor. Porque el objetivo de las pruebas unitarias es que prueban con precisión mi código tal como existe en este momento.