java - jsoninclude - JUnit''s @Ignore

objectmapper set ignore unknown (9)

Me pregunto si es una buena práctica usar @Ignore de JUnit. ¿Y cómo las personas lo están usando?

Se me ocurrió el siguiente caso de uso: digamos que estoy desarrollando una clase y escribiendo una prueba de JUnit para ella, que no pasa, porque aún no terminé la clase. ¿Es una buena práctica marcarlo con @Ignore?

Estoy un poco preocupado de que podamos perder el caso de prueba ignorado más adelante o que las personas comiencen a usarlo para "forzar" a las pruebas a pasar el IC.

Bueno, si no terminaste con la clase, es bueno que la prueba falle. Marcarlo como @Ignore significaría que enviará un código con la clase sin terminar. Y a la derecha, tal vez no estés usando esa clase aún en ningún código que se ejecute, pero algún día algún otro desarrollador podría ver esa clase y usarla. Luego falla, incluso debería funcionar.

No usaría @Ignore en ese caso, seguro.

Creo que usar @ignore está bien siempre y cuando haya -

Una buena razón por la cual el método no puede ser probado de alguna forma y está documentado como tal en el código. Este debería ser un caso especial y justifica una discusión o revisión del código para ver si hay alguna forma de probarlo.
La prueba aún no está construida; esto debería ocurrir solo para el código heredado. Esto también debe estar sujeto a la revisión del código y las tareas deben agregarse para agregar pruebas.

Esas son las reglas, al menos en mi mente ;-)

En mi humilde opinión, ignore que no se debe utilizar a la ligera ... debido al efecto de ventanas rotas.

Rara vez me encuentro usando este atributo / anotación en xUnit. Las únicas pocas veces que los he usado son como TESTIGO al escribir TestCase # 1, veo otro caso (s) de prueba que omití pero que también debería incluirse. Solo para no olvidarlo, escribo un pequeño caso de prueba con un nombre descriptivo y lo marco con Ignorar. Proceda a completar TestCase # 1. Pero esto es todo dentro de la facturación. Nunca controlo las pruebas marcadas con Ignorar.

Sin embargo, usualmente solo uso un pedazo de papel - lista de prueba para anotar el nuevo caso de prueba - que es mucho más simple. Esto también atiende al escenario en el que estoy parcialmente hecho ... completó 5 de 10 pruebas. En lugar de registrar 5 pruebas ignoradas, me quedaría con la lista de prueba y verificaría 5 pruebas aprobatorias. La suposición es que completarás el resto en los próximos chequeos antes de saltar a algo nuevo.

Otros ''casos especiales'' en los que puedo pensar es ...
Cuando está esperando un componente de otro equipo / persona / proveedor (cuya interfaz ha sido publicada-acordada), sin la cual las pruebas no se pueden ejecutar. En este caso, puede escribir las pruebas y marcarlas con Ignorar ("Esperando que X entregue el componente Y")

Uso rutinariamente @Ignore para las pruebas que fallan debido a un error conocido. Una vez que se confirma el error y se inicia sesión en las bases de datos de errores, la falla de la prueba no sirve para nada, ya que el error ya se conoce.

Aún así, tiene sentido mantener el código de prueba, porque será útil nuevamente una vez que se solucione el error. Así que lo marqué para ignorarlo, con un comentario que indica el error relacionado, e idealmente tenga en cuenta en el informe de error que la prueba debe ser reactivada para probar el arreglo.

Creo que esto va en contra de los fundamentos básicos del desarrollo impulsado por pruebas. Concedido si no estás haciendo TDD, probablemente no importe tanto.

Aunque diría que si utilizas @ignore, entonces no eres LEAN y no estás haciendo TDD.

Si está haciendo TDD, nunca debería tener pruebas fallidas en ningún compromiso que realice a su repositorio.

¿Estoy completamente loco o tiene sentido?

Creo que está bien utilizar @ Ignore cuando la prueba se basa en entidades externas que no se pueden burlar. Todavía necesitamos la prueba para asegurarnos de que las cosas funcionen, pero no queremos implementar una prueba que dependa de una dependencia externa.

Por ejemplo, si escribe un SpreadsheetWriter / Reader personalizado para documentos de Google, tiene sentido utilizar un documento de Google real para probarlo. Sin embargo, no le gustaría que su compilación falle si los documentos de Google están caídos por alguna razón. Después de confirmar que la prueba de su unidad pasa localmente, agregaría un @Ignore antes de pasarlo a producción.

En general, creo que @Ignore debe evitarse tanto como sea posible porque en la mayoría de los casos se pueden burlar las clases / sistemas externos.

@Ignore se puede usar en pruebas escritas para algunos servicios de terceros. Recientemente me vi en la necesidad de comprobar si el servicio externo está enviando los datos que esperaba. Fue muy conveniente hacer eso en la prueba (simulacros). Como sabía que mis datos de entrada no funcionarían para siempre y es posible que necesite ejecutar una prueba similar más tarde, agregué @Ignore lugar de eliminar la prueba.

Creo que es una excelente manera de usarlo.

Su servidor de CI debe ser verde (o azul en el caso de Hudson) todo el tiempo. Siempre que no sea su primera prioridad, es arreglarlo.

Ahora, si CI se rompió debido a un error en el código de la prueba (tal vez el código de la prueba es malo y no determinista) entonces simplemente debes ignorar la prueba "@Ignore (Este código de prueba es borken, defecto elevado # 123)" y aumentar el error en tu rastreador de defectos

No enviará código roto porque cada vez que envía, revisa todos los defectos y decide si alguno de ellos muestra los topes, ¿no? Una prueba rota que no se está ejecutando se considerará junto con el código / función que estaba probando. Envías solo si estás contento de que el código que estaba probando no esté roto. Si no está probado, considérelo roto.

Espero que el formateador de informes junit xml, utilizado al ejecutar pruebas de hormiga, incluya algún día el recuento ignorado (y los motivos) junto con el pase, el error y el error. Quizás entonces, los proveedores de CI incluirán los conteos de prueba ignorados (si no, tendré que escribir un plugin de Hudson ...)

Eso está bastante bien, supongo.

Los documentos dicen:

Los corredores de prueba informarán el número de pruebas ignoradas, junto con el número de pruebas que se realizaron y el número de pruebas que fallaron.

Por lo tanto, significa que incluso si olvida eliminarlo posteriormente, debería haber recibido una notificación al respecto.

El ejemplo dado en los documentos se asemeja completamente a su caso.

@Ignore("not ready yet")