¿Se me permite comprobar en una prueba no

Question

Nuestro equipo está teniendo un acalorado debate sobre si permitimos que no superen los ensayos de la unidad para ser facturado al control de código fuente.

Por un lado, el argumento es que sí, siempre que sea temporal, se resuelva dentro del sprint actual. Algunos dicen incluso que en el caso de errores que no pueden corregirse en el Sprint actual podemos comprobar en una prueba en su defecto correspondiente.

El otro lado del argumento es que esas pruebas, si se registran deben marcarse con el atributo Ignorar, el razonamiento es que la compilación nocturna no debe servir como lista TODO para un desarrollador.

El problema con el atributo Ignorar sin embargo, es que tendemos a olvidarnos de las pruebas.

tiene la comunidad algún consejo para nosotros?

Somos un equipo de 8 desarrolladores, con una acumulación de todas las noches. Personalmente estoy tratando de practicar TDD pero el equipo tiende a escribir pruebas unitarias después de que se escribe el código

Answer 1

yo diría que no sólo en caso de que no se verifique en las nuevas pruebas en su defecto, debe desactivar sus "más o menos 10 pruebas fallan a largo plazo". Es mejor arreglarlos, por supuesto, pero entre tener una versión fallada todas las noches y tener todas las pruebas incluidas aprobadas (con algunas excluidas), es mejor que estés verde. Tal como están las cosas ahora, cuando cambias algo que causa un nuevo fallo en tu conjunto de pruebas existentes, es muy probable que lo eches de menos.

Desactive las pruebas fallidas e ingrese un ticket para cada una de ellas; de esa manera lo conseguirás. También se sentirá mucho mejor con su sistema de compilación automatizado.

Answer 2

Depende de cómo se usan las pruebas. En mi grupo, ejecutar pruebas es lo que haces antes de un commit para verificar que (probablemente) no hayas roto nada.

Cuando está a punto de comprometerse, es doloroso encontrar pruebas fallidas que parecen posiblemente relacionadas con sus cambios pero que aún son extrañas, investigue durante un par de horas y luego se da cuenta de que no es posible debido a sus cambios, haga una limpie, compile y descubra que, de hecho, los fallos de prueba provienen del tronco.

Obviamente, usted no usa las pruebas de la misma manera, de lo contrario, ni siquiera se lo preguntaría.

Answer 3

Diría que las pruebas de fallas de comprobación (conocidas) deberían ser, por supuesto, solo temporales, en todo caso. Si la creación siempre falla, pierde su significado (hemos estado allí y eso no es bonito).

Supongo que estaría bien comprobar en las pruebas fallidas si encuentra un error y podría reproducirlo rápidamente con una prueba, pero el código ofensivo no es "suyo" y no tiene el tiempo/la responsabilidad de obtener en ella lo suficiente como para arreglar el código. Luego, déle un boleto a alguien que sepa qué hacer y apunte a la prueba.

De lo contrario, yo diría que use su sistema de tickets como una lista de cosas por hacer, no la compilación.

Answer 4

Si estuviera usando un DVCS (por ejemplo, git), esto no sería un problema ya que enviaría la prueba de falla a su repositorio local, la haría funcionar y luego empujaría todo el lote (prueba y solución) volver al repositorio principal del equipo. Trabajo hecho, todos contentos.

Como parece que no puedes hacer eso, lo mejor que puedes hacer es primero asegurarte de que la prueba está escrita y falla en tu sandbox, y luego corregirla antes de cometerla.Esto podría ser o no un gran TDD, pero es un compromiso razonable con las prácticas laborales de todos los demás; trabajando con sus compañeros de trabajo es más importante que después de algún principio torre de marfil en todos los aspectos, ya que el autor del principio no se encuentra en el cubículo de al lado ...

Answer 5

Hablé de esto con un amigo y nuestro primer comentario fue un geek reciente & poke :) (adjunta)

Para ser más específicos, todas las pruebas deben escribirse antes (siempre que se suponga que sean TDD) pero aquellos que verifiquen una funcionalidad no implementada deberían tener su valor antecedido con negación . Si no se implementa, no debería funcionar. [Si funciona - la prueba es mala] Después de implementar una prueba, eliminas el ! y funciona [o falla, pero está ahí para hacerlo :)].

No debería pensar que las pruebas son algo escrito una vez y siempre correctas. Las pruebas también pueden tener errores. Entonces, editar una prueba debería ser normal.

Answer 6

El propósito de su creación nocturna es para darle la confianza de que el código escrito el día anterior no ha roto nada. Si las pruebas a menudo están fallando, entonces no puedes tener esa confianza.

Primero debe corregir las pruebas de falla que pueda y eliminar o comentar/ignorar las otras fallas. Cada construcción nocturna debe ser verde. Si no es así, entonces hay un problema y eso es inmediatamente obvio ahora ya que debería haberse puesto verde.

En segundo lugar, nunca debe verificar en las pruebas de falla. Nunca debes romper la compilación a sabiendas. Nunca. Causa ruido innecesario, distracciones y disminuye la confianza. También crea una atmósfera de holgazanería en torno a la calidad y la disciplina. Con respecto a las pruebas ignoradas que se registran, estas deben captarse y abordarse en las revisiones de su código, que también deberían abarcar su código de prueba.

Si la gente quiere escribir su código primero y pruebas más tarde, esto está bien (aunque yo prefiero TDD), pero sólo el código probado que funciona verde deben verificarse en.

Por último, recomiendo el cambio de la noche crear una compilación de integración continua (ejecutar en cada registro de código) que podría cambiar los hábitos de las personas en torno al registro de código.

Answer 7

Veo que tiene una serie de problemas.

1) Está escribiendo pruebas fallidas.

Esto es genial! Sin embargo, alguien tiene la intención de verificar los que están "para ser reparados dentro del sprint actual". Esto me dice que está tardando demasiado en hacer que pasen esas pruebas unitarias. O bien las pruebas cubren más de uno o dos aspectos del comportamiento, o su código subyacente es demasiado complejo. Refactorice el código para dividirlo y use simulaciones para separar las responsabilidades de la clase bajo prueba de sus colaboradores.

2) Tiende a olvidarse de las pruebas con atributos [Ignorar].

Si está entregando código que a las personas les importa, o funciona, o tiene errores que requieren que se modifique el comportamiento del sistema. Si las pruebas de su unidad describen ese comportamiento pero el comportamiento aún no funciona, entonces no lo olvidará porque alguien habrá registrado un error. Sin embargo, vea el punto 1).

3) Su equipo está escribiendo pruebas después de escribir el código.

Esto es bastante común para los equipos que aprenden TDD. Podrían encontrarlo más fácil si pensaran que las pruebas no son como pruebas para verificar si su código está roto, sino ejemplos de cómo otro desarrollador podría querer usar su código, con una descripción del valor que proporciona su código. ¿Quizás podría emparejarse con ellos y ayudarlos a aprender de lo que ya saben sobre cómo escribir pruebas después?

4) Está intentando practicar TDD.

Hacer o no. Aquí no hay intentos. Primero escribe una prueba o no. El aprendizaje nunca se detiene incluso cuando piensas que estás haciendo TDD bien.