TDD, nuevas pruebas mientras que las anteriores aún no están implementadas

13

Estoy experimentando con un desarrollo guiado por pruebas, y descubrí que a menudo llego a una situación siguiente:

  1. Escribo pruebas para alguna funcionalidad X. Esas pruebas fallan.
  2. Al intentar implementar X, veo que necesito implementar alguna característica Y en una capa inferior de mi código. Entonces ...
  3. Escribo pruebas para Y. Ahora ambas pruebas para X e Y fallan.

Una vez tuve cuatro funciones en diferentes capas de código en las que se estaba trabajando al mismo tiempo, y estaba perdiendo mi enfoque en lo que realmente estaba haciendo (demasiadas pruebas fallando al mismo tiempo).

Creo que podría resolver esto si me esfuerzo más en la planificación de mis tareas incluso antes de comenzar a escribir las pruebas. Pero en algunos casos no sabía que necesitaría profundizar más, porque, por ejemplo, No conocía muy bien la API de la capa inferior.

¿Qué debo hacer en tales casos? ¿TDD tiene alguna recomendación?

    
pregunta liori 25.06.2011 - 16:02

5 respuestas

9

Lo bueno es que te das cuenta de que tu código bajo prueba necesita asistencia. En lugar de implementarlo de inmediato, cree una interfaz y use simulacros para asegurarse de que las pruebas etiquetan el código correcto. Una vez que haya aprobado esas pruebas, puede continuar con la implementación del código en el que se basa.

    
respondido por el Michael Brown 25.06.2011 - 16:30
4

Se pueden usar stubs y mocks para simular la funcionalidad que aún no se está modificando / implementando. También pueden ayudarlo a resolver las dependencias que causan este tipo de "reacción en cadena".

Por otro lado, tal vez mantener la única prueba (que falla) de que el próximo cambio es el mejor enfoque es el mejor.

Otras pruebas que tienen como objetivo el código que se basa en una nueva funcionalidad pueden desactivarse temporalmente, ya que no son realmente relevantes en este punto, es decir. en su caso, desactive las pruebas para X hasta que implemente Y etc.

De esa manera, puedes concentrarte en el próximo cambio, que es lo que quieres, creo.

    
respondido por el ratkok 25.06.2011 - 17:14
3

Detener

Parece que puede haber dos problemas separados aquí:

  1. olvidó algunas historias y escenarios de prueba, y no los descubrió hasta que comenzó a trabajar en un escenario de prueba en particular, y / o

  2. en realidad estás haciendo pruebas unitarias, y no TDD característica probando

Para el # 1, detente , regrese y actualice las historias y los escenarios de prueba, luego comience de nuevo con un escenario diferente.

Para # 2, detener , y recuerde que está probando características, no unidades, así que utilice simulacros para pasar por alto otras interfaces y / o implemente más código para hacer que la prueba pase sin agregar nuevos escenarios de prueba. Esto supone que no te faltan los escenarios de prueba, sino que, en lugar de eso, y esto es muy común, es la combinación de pruebas de unidad y TDD.

    
respondido por el Steven A. Lowe 25.06.2011 - 23:28
0

Esta es una gran pregunta y una frustración ENORME para mí también con TDD. Siento que TDD carece de este escenario en el que no tiene forma de saber qué componentes o funciones de nivel inferior necesitará hasta que comience a desarrollar.

Personalmente, encontré que TDD solo funciona si sabes exactamente lo que debes hacer y lo que necesitas llamar para realizar una función. Los desarrolladores no siempre saben todo antes de comenzar, por lo que he encontrado la mejor manera de mitigar la situación que describe:

Prototipo

Cuando hago aplicaciones de prototipos simples para explorar y descubrir métodos y enfoques para un problema técnico, descubro un montón de trabajo de la pierna y desactivo esa investigación antes de comenzar. El diseño y la estimación se vuelven mucho más fáciles también.

Si el prototipo tiene que estar tan involucrado que se convierta en la aplicación, le insto a que no haga las cosas perezosas y cree pruebas unitarias para su prototipo después del hecho.

Debería saber más sobre la API de nivel inferior en ese momento y ser capaz de burlarse con éxito de la API de nivel inferior en sus componentes de nivel superior.

    
respondido por el maple_shaft 25.06.2011 - 17:47
0

Depende de qué tipo de pruebas evalúes tu escritura mientras haces TDD.

El modelo clásico es escribir pruebas unitarias y hacer uso de simulacros o talones para desacoplar la prueba de las otras "unidades" del código.

Hay muchos otros modelos alternativos, como ATDD, donde la prueba es de pila completa o de pila casi completa. En este caso particular, sus pruebas de escritura que afirman el comportamiento requerido del programa no son una sola unidad de código, por lo que no estaría escribiendo otras pruebas. Usted obtendría el implemento de ida y vuelta para satisfacer la prueba. Luego agrega otras pruebas para otras características / comportamientos.

    
respondido por el dietbuddha 26.06.2011 - 08:29

Lea otras preguntas en las etiquetas