Tiene una unidad/prueba de integración sin afirmar que exista?

Question

Recientemente tuve la oportunidad de ver un montón de pruebas sin ninguna afirmación. Esas pruebas tenían que ser pruebas de precisión.

Creo que lo único que se puede probar con estas pruebas es comprobar si no se producen excepciones durante el flujo de ejecución. Pero de todos modos, realmente no entiendo cómo podemos verificar la exactitud del código sin pruebas afirmativas, incluso los métodos que no hacen nada pueden pasar tales pruebas.

Así que me pregunto qué puede ser el propósito de tales pruebas y qué más se puede probar con eso?

Answer 1

Les dejaría tener derecho a existir si están probando algún "código heredado", código que nadie realmente tiene un buen control. No, si están ahí para mostrar una "alta cobertura de código".

Es un primer paso para obtener algo de confianza en el código. El control invisible es: "no se lanzan excepciones". Sin embargo, una vez que hayas completado la aplicación en algunas pruebas de humo como estas, el siguiente paso sería convertir la verificación implícita en un control explícito; ponte tu límite de pensamiento y crea cambios observables que puedes afirmar de tus pruebas.
Puede usar herramientas como TestLint para detectar pruebas como estas.

Answer 2

A veces es interesante saber que una parte del código se puede ejecutar en absoluto.

Lo hago para el código (Python) que produce una salida gráfica, por ejemplo. Estoy feliz de que el gráfico se haya creado. Cuando la prueba falla, sé que algo está roto.

Answer 3

Aquí es un ejemplo (C#, NUnit):

[Test] 
public void StartUpShutDownDoesntThrow() { 
    var aService = new Service(); 
    aService.StartUp(); 
    aService.ShutDown(); 
} 

Si esta prueba pasa asegura lo siguiente:

• El constructor no lanzar una excepción
• de inicio() no lanza una excepción
• ShutDown() no lanza una excepción

Los tres elementos son valiosos, tal vez incluso épicos. Se sorprenderá de cuántas aplicaciones comerciales ni siquiera tienen algo tan básico como esto como parte de su proceso de control de calidad.

Así que, sí, las pruebas sin afirmaciones también pueden tener su valor.

Answer 4

Sí, como @John y @Olivier señalan, en ocasiones es valioso saber simplemente que algún código se ejecuta sin lanzar excepciones (y, supongo, no hace falta decirlo, sin errores de compilación). Pero estas son ocasiones excepcionales, y bajo ninguna circunstancia consideraría estas pruebas de "precisión".

Answer 5

Podrían ser pruebas de humo diseñadas para demostrar que algo no arroja una excepción o algo más está arrojando haciendo el trabajo (como un objeto simulado).

Sea cual sea el motivo, creo que debe cambiar el nombre de las pruebas como si la gente no supiera por qué existen o qué están probando, cómo se pueden reparar si se rompen.

Answer 6

En mi humilde opinión, las pruebas deben probar el comportamiento, no la falta de comportamiento. Si desea probar excepciones, pruebe las excepciones. Read this blog publicación.Tal vez estas pruebas sean pruebas para que los jugos de prueba fluyan, pero no deberían durar mucho.

Answer 7

Umh, no!

Una prueba sin Assert es claramente un olor de diseño. Eso se debe a que una buena prueba debe comunicarse exactamente por código QUÉ está probando, y también debe ser confiable.

Una prueba de la forma

[Test] 
public void DoSomethingDoesNotThrow() 
{ 
    var aService = new Service(); 
    aService.DoSomething(); 
} 

no tiene sentido, incluso potencialmente dañino, porque va a pasar, independientemente de lo aService.DoSomething() `está haciendo. Pero el mayor problema es: no prueba nada. (Y btw: ¿Cómo podría esta prueba 'precisión'?)

¡Sería mejor probar alguna funcionalidad de aService.DoSomething() en su lugar! Si se aprueba una prueba de este tipo, usted sabe que no se produce ninguna excepción, entonces ¿por qué necesitaría una 'prueba' como la anterior?

En general: siempre pruebe los hechos, nunca la ausencia de estos hechos.

Sólo porque se hace a menudo en el mundo real no significa que sea una buena práctica ...

Thomas

Answer 8

Recientemente tuve un error relacionado con una clase llamada impropiamente-tan escribió una prueba para compruebe que existió la clase correctamente nombrada (podría crearse una instancia).

Naturalmente, la prueba falló y no vi la necesidad de un Assert aquí.

Al arreglar los resultados del nombre de clase en una prueba de aprobación, me pregunté si necesitaba un Assert aquí también.

Al final solo afirmé que la clase que se había creado era del tipo correcto, lo cual parecía bastante inútil pero lo hizo de todos modos.

En este escenario, todavía siento que no se requiere el Assert.

¿Alguna idea de esto?