¿Cómo se usan comúnmente los objetos simulados?

Hace poco leí un artículo que decía que los objetos simulados a menudo son mal entendidos y mal utilizados. ¿Hay algún antipatrón burlón claro que pueda tener en cuenta?

Odio ver burlas de clases concretas simples. Por ejemplo, tome la siguiente clase simple que no depende de nada más:

public class Person
{
    private readonly string _firstName;
    private readonly string _surname;

    public Person(string firstName, string surname)
    {
        if (String.IsNullOrEmpty(firstName))
        {
            throw new ArgumentException("Must have first name");
        }

        if (String.IsNullOrEmpty(surname))
        {
            throw new ArgumentException("Must have a surname");
        }

        _firstName = firstName;
        _surname = surname;
    }

    public string Name 
    {
        get
        {
            return _firstName + " " + _surname;
        }
    }
}

En cualquier prueba que involucre esta clase, preferiría que se creara una instancia real y se usara en lugar de que se extrajera alguna interfaz como 'IPerson', se usó una simulada y se establecieron expectativas. Al usar el real, su prueba es más realista (tiene las verificaciones de parámetros en su lugar y la implementación real de la propiedad 'Nombre'). Para una clase simple como esta, no está haciendo que sus pruebas sean más lentas, menos deterministas o enturbia la lógica (es probable que no necesite saber que se llamó a Nombre cuando se prueba alguna otra clase), que son las razones habituales para burlarse / tropezar

Como una extensión de esto, también he visto a personas escribir pruebas donde el simulacro se configura con una expectativa, luego el simulacro se llama directamente en la prueba. Como era de esperar, la prueba siempre pasará ... hmmmm ...

Puede sonar obvio, pero: ¡No uses objetos simulados en el código de producción! He visto más de un ejemplo en el que el código de producción dependía de las características de ciertos objetos simulados ( MockHttpServletRequestdel Springframework, por ejemplo).

En mi opinión, es el método excesivo de verificación de invocación en simulacros. Siento que esta es una práctica impuesta por algunos marcos de simulación como EasyMock, donde el comportamiento simulado predeterminado es fallar siempre que haya una invocación de método adicional que no se especificó exactamente antes. Este tipo de comprobación estricta de métodos simulados puede conducir a diseños frágiles donde el más mínimo cambio en el código puede llevar a que falle un conjunto completo de pruebas, a pesar de que la funcionalidad principal sigue siendo la misma.

Una solución a esto es comenzar a usar trozos en lugar de simulacros. Un artículo que encontré particularmente esclarecedor sobre el tema fue uno que se encuentra en el Javadoc de Mockito: http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html (ver "2. ¿Qué tal un poco de tropezón?" ), enlace a: http://monkeyisland.pl/2008/07/12/should-i-worry-about-the-unexpected/ .

Me ha encantado trabajar con Mockito hasta ahora porque no impone este estricto comportamiento de burla, sino el uso de stubs. También impone el método de verificación de los específicos en lugar del objeto simulado completo; así que terminas comprobando solo los métodos que realmente importan en tu escenario de prueba.

Hay algunos libros aquí y allá que puedo recomendar que toquen este tema y burlas y en general:

xUnit Patrones

El arte de las pruebas unitarias: con ejemplos en .Net

Pruebas Java de próxima generación: TestNG y conceptos avanzados (este libro trata principalmente sobre testNG pero hay un buen capítulo sobre burlas)

He observado pocos antipatrones en mi experiencia.

• Las clases de dominio se burlan / se aprietan donde puede ocurrir un cambio de estado y eso debe verificarse.
• Pruebas de integración que interactúan con una mezcla de simulacros y clases concretas que anula el propósito de las pruebas de integración.
• Uso inadvertido de simulacros en el código de producción (Esto nunca debería suceder)

De lo contrario, mi experiencia con simulacros, especialmente Mockito, ha sido muy fácil. Han hecho pruebas muy fáciles de escribir y mantener. La prueba de interacción de vista / presentador de GWT es mucho más fácil con simulacros que el GWTTestCase.

Encuentro que las pruebas que utilizan simulacros en múltiples capas de una aplicación son particularmente difíciles de descifrar y cambiar. Sin embargo, creo que esto se ha mitigado en los últimos años gracias a las API de marco simulado mejoradas (uso JMock cuando es conveniente).

Hace 5 o 6 años, las API como EasyMock eran poderosas pero muy engorrosas. A menudo, el código de prueba que lo utilizaba era un orden de magnitud más complicado que el código que estaba probando. En aquel entonces traté de influir en los equipos en los que estaba para usarlo con moderación y conformarme con simples simulacros artesanales que eran simplemente implementaciones alternativas de interfaces específicamente para pruebas.

Recientemente, mis fuertes opiniones sobre esto se han vuelto más suaves a medida que las API burlonas han hecho que las pruebas que las utilizan sean más legibles. Esencialmente, quiero que otros desarrolladores puedan cambiar mi código (incluidas las pruebas) sin hacerlos sentir como si estuvieran analizando una serie de oscuras llamadas API.