Deberíamos eliminar las pruebas que son demasiado simples de romper durante TDD

He estado tratando de mantener el enfoque TDD. Así que hice algunas pruebas y todas fallaron. Ahora estoy implementando. Pero ahora que estoy implementando, he visto que los métodos son demasiado simples para fallar. En particular, he implementado el patrón de observación y todo lo que ocurre es que notifico a todos los observadores registrados. Entonces use a para cada ciclo y llame notifique. Esto ciertamente suena demasiado simple para romperlo. Ahora que tengo las pruebas en lugares ¿debería eliminarlos? Esto también parece ser una pérdida de tiempo. Entonces, ¿debería intentar anticipar métodos que serían demasiado simples de romper?Deberíamos eliminar las pruebas que son demasiado simples de romper durante TDD

Fuente

2010-02-11 uriDium

Nº

Los métodos pueden ser demasiado simple para romper este momento, pero eso no quiere decir que nunca necesitan ser modificadas (y posiblemente rota) en el futuro.

Fuente

2010-02-11 09:56:07

Gracias por el comentario. Entonces debería dejarlos por el momento y agregarlos más tarde si el método cambia. El peligro evidente es que olvide actualizar la prueba unitaria. PERO incluso al hacer cambios, primero debemos escribir una prueba unitaria para el cambio, así que debemos atraparlo. – uriDium

Deje la prueba simple allí, si el método necesita cambiar, y es un cambio de rotura, entonces tendrá que modificar las pruebas de la unidad. Sin embargo, si no se trata de un cambio radical y las pruebas dejan de funcionar, entonces hay un error en su cambio. –

que estás diciendo esto es demasiado simple para fallar:

for (i = 0; i < observers.length; ++i) { 
    // Notify observer observers[i] 
}

Es tentador pensar que, pero tenga en cuenta este error común:

for (i = 0; i <= observers.length; ++i) { 
    // Notify observer observers[i] 
}

O esta otra:

for (i = 0; i < observers.length; ++j) { 
    // Notify observer observers[i] 
}

O quizás los observadores no se agregan correctamente. O ... o ... o ...

Si ya tiene las pruebas, no parece necesario para eliminarlos, y un axioma de software es las funciones tienden a crecer con el tiempo, así que lo que es ahora sencilla puede ser menos complicado: exactamente el tipo de cosa en la que se supone que te ayudarán tus exámenes.

Fuente

2010-02-11 09:57:46

No a Para cada declaración. La instrucción For Each es una construcción de lenguaje, por lo que básicamente se trata de volver a probar el compilador. Si fuera un ciclo normal con int i = 0 etc. entonces lo haría. – uriDium

@uriDium: Está bien (no indicaste qué lenguaje o construcción estabas usando, así que fui con un denominador común). El punto sigue en pie; Prácticamente nada es demasiado simple para equivocarse de alguna manera, y las funciones tienden a crecer en complejidad con el tiempo. –

@ T.J. Estoy de acuerdo, puede que no tenga sentido probar foreach, sin embargo, también está probando el bloque iterador, que dice que no será un iterador personalizado, por supuesto debería tener sus propias pruebas, pero ¿quién dice esto foreach? no encontrará algo que esas pruebas hayan pasado por alto. –

Sí; Si está probando la funcionalidad del compilador/máquina virtual subyacente, su prueba es demasiado simple. A menos que, es decir, no confíe en esa pieza particular del compilador/máquina virtual que se está ejerciendo.

Pero, por supuesto, la realidad de las pruebas es un poco más compleja que solo una respuesta sí/no a esta pregunta. Como se indicó en otra respuesta, si ya ha escrito las pruebas, no las elimine. Pero tampoco debe usarlos en un contexto de cobertura de código como argumento para la confianza.

Fuente

2010-02-11 09:58:04 Steen

Nº

Lo estás haciendo exactamente bien: escribir pruebas que fallan en primer lugar, a continuación, la fijación de ellos. Deje esos exámenes solo, escriba los más complejos en el futuro si cree que los necesitará (por ejemplo, para reproducir errores).

Fuente

2010-02-11 10:01:09

Cuantas más pruebas tenga, menos dolor tendrá en el futuro. No importa su simplicidad.

Fuente

2010-02-11 10:01:20 Kerido

Ahora que ha pasado todas esas pruebas, déjelas en paz. Si se están ejecutando con la suficiente rapidez, no serán una carga para nadie.

Sin embargo, en el futuro, es posible que desee escribir solo una prueba de falla a la vez. (Ver The Three Rules). Esto se debe a que permitirá que su diseño mejore mientras desarrolla su código.

Cuando fallaron todas las pruebas y no hubo ninguna implementación que haya arreglado su diseño y ahora funciona, es posible que detestara la refactorización del diseño para mejorarlo.

También sospecho que tuvo un momento complicado para implementar su código, ya que cada paso de la implementación podría haber roto más pruebas de las que se aprobaron, pero bueno, ¡solo estoy adivinando!

Fuente

2010-02-14 22:29:16 quamrana

Deberíamos eliminar las pruebas que son demasiado simples de romper durante TDD

Respuesta

Cuestiones relacionadas