¿Por qué esta prueba en particular podría ser útil?

Question

Hace poco se unió a una empresa en la que usan TDD, pero todavía no está claro para mí, por ejemplo, tenemos una prueba:

[TestMethod] 
public void ShouldReturnGameIsRunning() 
{ 
    var game = new Mock<IGame>(); 
    game.Setup(g => g.IsRunning).Returns(true); 
    Assert.IsTrue(game.Object.IsRunning); 
} 

¿Cuál es la finalidad de la misma? Por lo que yo entiendo, ¡esto no prueba nada! Lo digo porque se burla de una interfaz, y diciendo, devuelve true para IsRunning, nunca devolverá un valor diferente ...

Probablemente estoy pensando mal, ya que todo el mundo dice que es una buena práctica, etc. o esta prueba es incorrecta?

Answer 1

La prueba no es válida. Moq es un marco utilizado para "simular" objetos utilizados por el método bajo prueba. Si estaba probando IsRunning, puede usar Mock para proporcionar una cierta implementación para los métodos de los que depende IsRunning, por ejemplo, para ejecutar ciertas rutas de ejecución.

Las personas pueden decirle todo el día que primero las pruebas son mejores; no se dará cuenta de que realmente es así hasta que empiece a hacerlo usted mismo y se dé cuenta de que tiene menos errores con el código para los que escribió pruebas primero, lo que le ahorrará tiempo a usted y a sus compañeros de trabajo y probablemente aumentará la calidad de su código.

Answer 2

Podría ser que la prueba haya sido escrita (antes) con el código que es una buena práctica.

También podría ser que esta es una prueba sin sentido creada por una herramienta.

Answer 3

Esta prueba consiste en una interfaz y verifica que la interfaz expone un captador booleano llamado IsRunning.

Esta prueba probablemente se escribió antes de que existiera el interface, y probablemente mucho antes de que existieran clases concretas de IGame. Me imagino que, si el proyecto es de alguna madurez, existen otras pruebas que ejercen las implementaciones reales y verifican el comportamiento para ese nivel, y probablemente usan la burla en el contexto aislacionista más tradicional en lugar de anotar las formas teóricas.

El valor de este tipo de pruebas es que obliga a pensar cómo se va a utilizar una forma u objeto. Algo así como "No sé exactamente qué va a hacer un juego todavía, pero sí sé que voy a querer comprobar si se está ejecutando ...". Por lo tanto, este estilo de prueba es más para impulsar las decisiones de diseño, así como para validar el comportamiento.

No es la prueba más valiosa del planeta, pero cumple su función en mi opinión.

Editar: Yo estaba en el tren anoche cuando estaba escribiendo esto, pero quería dirigirme a Andrew Whitaker para comentar directamente en la respuesta.

Se podría argumentar que la firma en la interfaz en sí es suficiente para hacer cumplir el contrato deseado. Sin embargo, esto realmente depende de cómo trate sus interfaces y, finalmente, de cómo valide el sistema que está tratando de probar.

Puede haber un valor tangible al declarar explícitamente esta funcionalidad como una prueba. Está verificando explícitamente que esta es una funcionalidad deseada para un IGame.

Tomemos un caso de uso, digamos que como diseñador sabe que quiere exponer un getter público para IsRunning, por lo que lo agrega a la interfaz.Pero digamos que otro desarrollador obtiene esto y ve una propiedad, pero no ve ningún uso de ella en ningún otro lugar en el código, se puede suponer que es elegible para eliminación (o eliminación de eliminación de código, que normalmente es algo bueno)) sin daño La existencia de esta prueba, sin embargo, establece explícitamente que esta propiedad debería existir.

Sin esta prueba, un desarrollador podría modificar la interfaz, abandonar la implementación y el proyecto aún se compilaría y ejecutaría aparentemente correctamente. Y sería hasta mucho después que alguien note que la interfaz ha cambiado.

Con esta prueba, aunque parezca que nadie está usándola, su conjunto de pruebas fallará. La naturaleza autodocumentada de la prueba indica que ShouldReturnGameIsRunning(), que al menos debe engendrar una conversación si IGame realmente expone un getter IsRunning.

Answer 4

Otra posibilidad es que el código fue escrito por alguien que, en ese momento, no entendía cómo usar ese marco burlón particular, y escribió una o más pruebas simples para aprender. Kent Beck habló sobre ese tipo de "prueba de aprendizaje" en su libro TDD original.

Answer 5

Esta prueba podría haber tenido un punto en el pasado. Podría haber estado probando una clase concreta. Podría haber estado probando uno abstracto, ya que a veces tiene sentido burlarse de una clase abstracta que desea probar. Puedo ver cómo un (menos informado (como yo)) seguidor de la forma TDD de hacer las cosas podría haber dejado un pequeño desastre como este. La limpieza del código muerto y del código de prueba muerto, no encaja realmente en el flujo de trabajo natural del refactor rojo, verde (¡ya que no interrumpe ninguna prueba!). Sin embargo, la historia no justifica una prueba que no hace más que confundir al lector. Entonces, sé un buen boyscout y quítalo.

Answer 6

en mi opinión honesto, esto es sólo basura, que sólo demuestra que moq funciona como se espera