En TDD, ¿las pruebas deberían ser escritas por la persona que implementó la característica bajo prueba?

Question

Ejecutamos un proyecto en el que queremos resolver con un desarrollo basado en pruebas. Pensé en algunas preguntas que surgieron al iniciar el proyecto. Una pregunta fue: ¿Quién debería escribir la prueba unitaria para una función? ¿Debería la unidad de prueba ser escrita por el programador de implementación de funciones? ¿O debería la prueba unitaria ser escrita por otro programador, que define qué debería hacer un método y el programador implementador de características implementa el método hasta que se ejecuten las pruebas?
Si entiendo el concepto de TDD de la manera correcta, el programador de implementación de características tiene que escribir la prueba por sí mismo, porque TDD es un procedimiento con mini-iteraciones. Entonces, ¿sería demasiado complejo tener las pruebas escritas por otro programador?
¿Qué dirías? ¿Deberían las pruebas en TDD ser escritas por el programador o debería otro programador escribir las pruebas que describan lo que un método puede hacer?

Answer 1

En TDD, el desarrollador primero escribe las pruebas unitarias que fallan y luego corrige el código de producción para hacer pasar la prueba. La idea es que los cambios se realicen en pasos realmente pequeños, por lo que se escribe una prueba que llama a un método que no existe, luego se corrige agregando un método vacío, luego se agrega una afirmación al examen sobre el método. por lo tanto, falla nuevamente, luego implementa el primer corte del método, etc. Debido a que estos pasos son tan pequeños, no es práctico que una persona por separado escriba las pruebas. Por otro lado, recomendaría el emparejamiento, para que ganes algunos globos oculares adicionales asegurándote de que el código tenga sentido.

Creo que sería posible tener otra persona/equipo/o incluso un cliente (cuando use herramientas como Fitness) para escribir pruebas de aceptación, que prueben la funcionalidad completa en un nivel superior.

Answer 2

La Prueba Unitaria debe escribirse antes de la codificación y probar que una Unidad cumpla con los requisitos, por lo tanto, el desarrollador que implementa el código debe estar bien para escribir también la Prueba Unitaria.

Answer 3

Uno de los beneficios de TDD es el ciclo de respuesta rápida. Tener otro desarrollador que escriba las pruebas ralentizaría demasiado el proceso. El mismo desarrollador debe escribir ambos.

Answer 4

Podría hacerse de ambas formas, podría escribir la prueba de la unidad usted mismo, o elegir el método ping pong donde se turnan con otras pruebas de unidad de escritura del desarrollador y escribir la implementación si está emparejando. La solución correcta es la que funciona para usted y su equipo. Prefiero escribir la prueba yo mismo, pero conozco a otros que también han tenido suerte con el enfoque de ping pong.

Answer 5

Según la respuesta de Justin, no solo es correcto para el desarrollador de implementación escribir la prueba, sino que es el estándar de facto. En teoría, también es aceptable que otro programador escriba la prueba. He jugado con la idea de un programador de "prueba" que soporte a un desarrollador de "características", pero no he encontrado ejemplos.

Si escribo una prueba para un objeto, además de las entradas y salidas que espero, tengo que conocer la interfaz que expone. En otras palabras, las clases y métodos bajo prueba deben decidirse antes de que comience el desarrollo. En doce años, solo he trabajado una vez en una tienda que logró esa granularidad de diseño antes de que comenzara el desarrollo. No estoy seguro de cuáles han sido tus experiencias, pero no me parece muy ágil.

Answer 6

Creo que debe separar las Pruebas unitarias automatizadas del Desarrollo controlado por prueba. (en mi humilde opinión no es solo usted quien debe hacer una distinción vital aquí).

AUT recomienda encarecidamente que TDD requiera que se escriba primero la prueba.

TDD además hace que la prueba sea una parte esencial del proceso del código de escritura. TDD no es tanto un método de garantía de calidad, sino una forma de pensar sobre el código, por lo que las responsabilidades por separado serían contrarias a la filosofía de TDD. Tampoco serían prácticos: los nuevos ciclos de prueba/nuevo código son muy pequeños, por lo general son cuestión de minutos. Según tengo entendido, Test Driven Design sería una mejor descripción.

AUT se puede instalar en una base de código existente (aunque a menudo mal, dependiendo del tamaño y la estructura de la base de código). Las responsabilidades separadas pueden tener algunas ventajas aquí. Aún así, AUT ejerce una cierta presión sobre el diseño, por lo que la separación sería en el que escriba el código nivel.

---

Distinción: libremente admito que no me gusta la idea de TDD. Podría funcionar bien para cierto tipo de codificador, para ciertas aplicaciones, en ciertos mercados, pero todos los ejemplos, demos y tutoriales que he visto hasta ahora me hacen estremecer. OTOH, considero AUT una herramienta valiosa para garantizar la calidad. One herramienta valiosa.

Answer 7

Estoy un poco confundido aquí.

Usted dice que quiere usar TDD y parece entenderlo correctamente que un programador escribe una prueba, luego el mismo programador escribe la implementación y lo hace en los siguientes segundos/minutos después de escribir la prueba. Eso es parte de la definición de TDD. (Por cierto, "el mismo programador" también significa "el otro programador del par" cuando practica la programación de pares).

Si quieres hacer algo diferente, entonces ve y escribe tus experiencias en un blog o artículo.

Lo que no debes hacer es decir que lo que haces diferente es TDD.

La razón de 'el mismo programador' escribir la aplicación, y escribir muy pronto después de la prueba es a los efectos de retroalimentación rápida, para descubrir cómo escribir buenas pruebas, cómo diseñar software bien y cómo escribir buenas implementaciones

Consulte The Three Rules Of Tdd.

Answer 8

Las pruebas unitarias y las pruebas de aceptación son dos cosas diferentes, que pueden (y deben) hacerse en TDD. Las pruebas unitarias se escriben desde el punto de vista del desarrollador, para asegurarse de que el código está haciendo lo que ella espera. Las pruebas de aceptación se escriben desde el punto de vista del cliente, para asegurarse de que el código cumpla con las necesidades apropiadas. Puede tener mucho sentido que las Pruebas de aceptación sean escritas por otra persona (generalmente porque requiere una mentalidad y un conocimiento del dominio ligeramente diferentes, y porque se pueden hacer en paralelo), pero el desarrollador debe escribir las pruebas de unidad.

TDD también dice que no debe escribir ningún código, excepto en respuesta a una prueba fallida, por lo que tener que esperar a que otra persona escriba las pruebas unitarias parece bastante ineficiente.