¿Es viable TDD en proyectos colaborativos de código abierto?

Digamos que quería comenzar un proyecto de código abierto que espero / espero que mucha gente envíe parches y otras cosas. ¿Es viable adoptar un enfoque estricto de TDD? ¿Puedo / debo esperar / confiar en los colaboradores para escribir pruebas de calidad cada vez que envían un parche?

Una cosa en la que he estado pensando es escribir conjuntos de pruebas para informes de errores individuales y solicitudes de características y requerir que todos los parches / solicitudes de extracción hagan pasar las pruebas, pero en ese momento parece que sería mejor simplemente escribir la característica / corrección de errores yo mismo.

Por lo que puedo decir, la mayoría de los principales proyectos de código abierto que usan TDD (o al menos escriben pruebas) parecen estar escritos principalmente por un individuo o equipo, donde es fácil aplicar prácticas como TDD.

open-source tdd collaboration DormoTheNord
fuente

Compartir su investigación ayuda a todos. Cuéntanos qué has probado y por qué no satisfizo tus necesidades. Esto demuestra que te has tomado el tiempo para intentar ayudarte a ti mismo, nos salva de reiterar respuestas obvias y, sobre todo, te ayuda a obtener una respuesta más específica y relevante. También vea Cómo preguntar

mosquito

@gnat He buscado en StackExchange, y ha habido algunas preguntas en las que la gente pregunta sobre ejemplos de proyectos de código abierto con pruebas unitarias, que no es lo mismo que mi pregunta. Según su solicitud, he agregado más información.

DormoTheNord

DormoTheNord Creo que @gnat se refería a ejemplos específicos y citados .

haneefmubarak

"Sería mejor escribir la función / corrección de errores yo mismo". ¿Con o sin pruebas? ¿Es usted un defensor de TDD o simplemente está verificando si es viable en este contexto?

JeffO

Por supuesto, puede / debe esperar que los colaboradores escriban pruebas de calidad cada vez que envían un parche. Eso no solo es beneficioso: es extremadamente común en grandes proyectos de código abierto hoy en día (puedo dar ejemplos si lo desea).

Benjamin Gruenbaum

Respuestas:

Realmente no se puede aplicar un enfoque TDD (prueba primero) en un proyecto de código abierto donde los parches pueden ser enviados por el público en general.

Lo que puede aplicar es que todos los parches deben tener un conjunto de casos de prueba para las correcciones incluidas en el parche y que esos casos de prueba, así como todos los casos de prueba existentes, deben pasar. Puede aplicar esto solo otorgando derechos de compromiso a unos pocos desarrolladores confiables que se sabe que usan y aceptan las políticas del proyecto y declarando públicamente que las presentaciones / solicitudes de extracción solo se incorporarán si vienen con casos de prueba aprobados (con cobertura suficiente).

Esto no garantiza que la prueba se escriba primero , pero sí asegura que la prueba se escriba .

Bart van Ingen Schenau
fuente

¿Seguramente el propietario del repositorio puede negarse a realizar cambios que no se ajusten a los estándares de calidad del proyecto? Quizás la calidad y la cantidad de las contribuciones se verían afectadas si a los contribuyentes no les gustara esto, pero eso no quiere decir que no se pueda hacer cumplir. ¿Seguramente?

Tom W

@TomW: ¿Cómo comprobaría que mi envío se crea de acuerdo con las prácticas de TDD y no, por ejemplo, con las pruebas escritas después de la implementación?

Bart van Ingen Schenau

Ah, ya veo lo que quieres decir. Supongo que es inevitable cierta pérdida de rigor, pero aún puede verificar que el código viene con pruebas, que las pruebas son lo suficientemente granulares y cubren todo lo que se supone que deben hacer. No estoy tan familiarizado con git, pero para una solicitud de extracción determinada, ¿es posible inspeccionar la secuencia de confirmaciones para ese conjunto de cambios para ver que el desarrollador siguió un proceso adecuado para producirlo?

Tom W

En otras palabras, no puede confirmar el proceso interno de uno, pero puede garantizar que el resultado cumpla con un determinado estándar. Requerir pruebas y asegurarse de que el diseño sea lógico está dentro del poder del propietario.

Adrian Schneider

Puede pedirle a la gente que envíe parches de prueba solamente antes de que se les permita trabajar en el código; Esto proporcionaría una oportunidad adicional para revisar el diseño planificado antes de que se escriba el código.

En la práctica, esto puede matar cualquier entusiasmo que las personas tengan por contribuir al proyecto, o podría encender el fuego en aquellos que están de acuerdo con su metodología.

Sin embargo, los revisores tendrían que ser muy buenos para cambiar las revisiones de diseño rápidamente, para no detener el desarrollo.

Alex Feinman
fuente