Estoy experimentando con el desarrollo basado en pruebas, y descubrí que a menudo llego a la siguiente situación:

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 que tenía 4 funciones en diferentes capas de código trabajando al mismo tiempo, y estaba perdiendo mi enfoque en lo que realmente estoy haciendo (demasiadas pruebas fallan al mismo tiempo).

Creo que podría resolver esto poniendo más esfuerzo en la planificación de mis tareas incluso antes de comenzar a escribir pruebas. Pero en algunos casos no sabía que tendría que 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?

Lo bueno es que se da cuenta de que su código bajo prueba necesita asistencia. En lugar de implementarlo de inmediato, cree una interfaz y use simulacros para asegurarse de que sus pruebas tageing el código correcto. Después de pasar esas pruebas, puede pasar a implementar el código en el que se basa.

Los stubs y los simulacros se pueden usar 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 solo una prueba (fallida) que impulse el próximo cambio es el mejor enfoque.

Otras pruebas que se dirigen al código que se basa en la nueva funcionalidad se pueden deshabilitar 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.

Detener

Por casualidad 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 se está haciendo pruebas unitarias, y no TDD función de las pruebas

Para el n. ° 1, deténgase , regrese y actualice las historias y los escenarios de prueba, luego comience de nuevo con un escenario diferente.

Para el n. ° 2, deténgase y recuerde que está probando características, no unidades, por lo tanto, utilice simulacros para pasar por alto otras interfaces y / o implemente más código para que la prueba pase sin agregar nuevos escenarios de prueba. Esto supone que no le faltan escenarios de prueba, sino que, en cambio, esto es muy común, combina pruebas de unidad y TDD.

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

Personalmente, descubrí que TDD solo funciona si sabes exactamente lo que debes hacer y a qué debes llamar para realizar una función. Los desarrolladores no siempre saben todo antes de comenzar, así que he descubierto que la mejor manera de mitigar la situación que usted describe es:

Prototipo

Cuando hago prototipos de aplicaciones simples para explorar y descubrir métodos y enfoques para un problema técnico, descubro mucho del trabajo preliminar y elimino esa investigación antes de comenzar. Diseñar y estimar se vuelve mucho más fácil también.

Si el prototipo tiene que estar tan involucrado que se convierta en la aplicación, le insto a que no haga lo perezoso, sin embargo, 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.

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

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

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