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 el código suficiente para pasar esa prueba. Con un conjunto completo de pruebas para pasar, no se llega al código en pequeños pasos, sino que se debe dar un gran salto para que todos pasen de una vez.
Ahora, si no se limita a escribir el código para que todos pasen "de una vez", sino que escriba el código suficiente para pasar una prueba a la vez, aún podría funcionar. Sin embargo, tendría que tener más disciplina para no solo seguir adelante y escribir más código del que necesita. Una vez que comienzas por ese camino, te dejas abierto a escribir más código del que describen las pruebas, lo que puede no probarse , al menos en el sentido de que no es conducido por una prueba y tal vez en el sentido de que no es necesario (o ejercido) por cualquier prueba.
Entender qué debe hacer el método, como comentarios, historias, una especificación funcional, etc., es perfectamente aceptable. Sin embargo, esperaría traducir esto en pruebas de una en una.
La otra cosa que puede perderse al escribir las pruebas de una vez es el proceso de pensamiento por el cual pasar una prueba puede incitarlo a pensar en otros casos de prueba. Sin un banco de pruebas existentes, debe pensar en el próximo caso de prueba en el contexto de la última prueba aprobada. 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 encontrando nuevas posibilidades que no había considerado a priori, pero que solo ocurrieron en el proceso de escribir el pruebas Existe el peligro de que pueda omitirlos a menos que tenga el hábito específico de pensar qué pruebas nuevas puedo escribir que aún no tengo.