Más allá de solo pensar en una cosa, un paradigma de TDD es escribir el menor código posible para pasar la prueba. Cuando escribe una prueba a la vez, es mucho más fácil ver la ruta para escribir solo el código suficiente para que la prueba pase. Con un conjunto completo de pruebas para aprobar, no se obtiene el código en pasos pequeños, sino que se debe dar un gran salto para que todos se aprueben de una sola vez.
Ahora, si no se limita a escribir el código para hacer que todos pasen "de una vez", sino que simplemente escriba el código suficiente para pasar una prueba a la vez, es posible que aún funcione. Sin embargo, deberías tener más disciplina para no solo seguir adelante y escribir más código del que necesitas. Una vez que empiezas por ese camino, te dejas abierto para escribir más código del que describen las pruebas, que puede ser no probado , al menos en el sentido de que no está dirigido por una prueba y quizás en el Sentir que no es necesario (o ejercitado) por cualquier prueba.
Bajar lo que debería hacer el método, como comentarios, historias, una especificación funcional, etc., es perfectamente aceptable. Sin embargo, esperaría traducirlas en pruebas una por una.
La otra cosa que puede pasar por alto al escribir las pruebas de una sola vez es el proceso de pensamiento mediante el cual pasar una prueba puede hacer que piense en otros casos de prueba. Sin un banco de pruebas existentes, debe pensar en el siguiente caso de prueba en el contexto de la última prueba que pasa. Como dije, tener una buena idea de lo que se supone que debe hacer el método es muy bueno, pero muchas veces me he encontrado con nuevas posibilidades que no había considerado a priori, pero que solo ocurrían en el proceso de escribir el pruebas Existe el peligro de que pueda pasarlo por alto a menos que adquiera el hábito de pensar qué nuevas pruebas puedo escribir que no tengo.