¿Cuándo usar stubs y mocks?

Question

Tengo esta confusión todo el tiempo. Si escribo un código que utiliza código falso para afirmar alguna operación, ¿cómo puedo confiar en mi implementación real cuando se inicia realmente utilizando los objetos reales en lugar de los falsos?

Por ejemplo, tengo este código -

[Test] 
    public void CanCreateContactsWithData() 
    { 
     using(ISession session = factory.OpenSession()) 
     using (ITransaction trans = session.BeginTransaction()) 
     { 
      _contactId = (long) session.Save(contact); 
      trans.Commit(); 
     } 

     Assert.AreNotEqual(0, _contactId); 
    } 

Este código prueba la implementación de un "contacto" objeto ya sea que se guarda en la base de datos o no. Si, por casualidad, utilicé un talón en lugar de una conexión de base de datos real, ¿necesito realizar una prueba por separado para almacenarlo en la base de datos? Y, ¿ustedes lo llaman como pruebas de integración?

Las respuestas son sinceramente apreciadas.

Answer 1

Martin Fowler tiene una buena discusión here.

de su artículo:

Meszaros utiliza el término de prueba dobles como término genérico para cualquier tipo de objeto de simulación utilizado en lugar de un objeto real para fines de prueba.El nombre proviene de la noción de un doble de acrobacias en las películas. (Uno de sus objetivos era evitar el uso de cualquier nombre que ya se utilizó ampliamente.) Meszaros continuación, define cuatro tipos particulares de doble:

• objetos ficticios se pasan alrededor, pero nunca utiliza realmente. Por lo general, solo se utilizan para llenar listas de parámetros.
• Los objetos falsos en realidad tienen implementaciones de trabajo, pero por lo general toman algún atajo que los hace inadecuados para la producción (una base de datos en la memoria es un buen ejemplo).
• Los comprobantes brindan respuestas predeterminadas a las llamadas realizadas durante la prueba, por lo general, no responden para nada fuera de lo programado para la prueba. Los talones también pueden registrar información sobre llamadas, como un talón de la puerta de enlace de correo electrónico que recuerda los mensajes que 'envió', o tal vez solo la cantidad de mensajes que 'envió'.
• Los mocks son de lo que estamos hablando aquí: objetos preprogramados con expectativas que forman una especificación de las llamadas que se espera que reciban.

De estos tipos de dobles, solo los simulacros insisten en la verificación del comportamiento.

Answer 2

Sí, usar una base de datos real sería una prueba más funcional o de integración, dependiendo de su definición. Personalmente, creo que las pruebas unitarias deben probar exactamente ese método, en forma aislada de todo lo demás. Por lo tanto, independientemente de si la sesión o la transacción funciona o no, su unidad de prueba debe asegurarse de que esos objetos serán llamados a hacer su trabajo cuando sea necesario, es ahí donde entran los simulacros y los trozos. Los usa para asegurar que su prueba unitaria está desacoplada de la funcionalidad externa para que pueda probarse como una unidad básica; idealmente de todos modos.

Answer 3

Debe probar el código que ha escrito. Si escribió el código del objeto de conexión a la base de datos, entonces pruébelo. De lo contrario, si es parte de una biblioteca con sus propias pruebas, puede simularlo y asumir que si el objeto de conexión pasa su propio conjunto de pruebas, entonces funciona.

Por ejemplo, no probaría llamadas a métodos de Hibernate, supongo que los desarrolladores de Hibernate ya lo han probado exhaustivamente. Pero yo sería probar que estaba llamando al método correcto, utilizando un simulacro para configurar esa expectativa.

Answer 4

Usa stubs cuando solo quiere que una función devuelva algún valor (o no haga nada). Realmente no te importa si la función fue llamada o no, solo quieres aislar cosas.

Los mocks son más potentes, ya que también puede realizar un seguimiento si se llamó a la función, cuántas veces, e incluso hacer cosas con los valores que obtiene su función.

En su caso, si quiere burlarse de la base de datos (por lo que se convierte en una prueba unitaria en lugar de funcional), puede simular ISession e ITransaction. Luego puede almacenar estos valores en la memoria y verificar si se guardaron los valores correctos.

Answer 5

La mayoría de los tipos de pruebas unitarias se trata de probar piezas individuales de código, y los trozos y burlas son simplemente herramientas que lo ayudan a probar pieza por pieza. Al probar las piezas individualmente, probablemente pueda probar cada pieza con mayor detalle, pero no se le garantizará nada acerca de la imagen completa. Varios tipos de pruebas de integración harán eso.

Al probar funciones más grandes, a menudo encuentro que las pruebas de integración reales de la lógica de la base de datos son los artefactos de prueba menos valiosos, ya que a menudo se probarán estas mismas operaciones en el nivel de UI.