Ágil sin pruebas unitarias

¿Tiene sentido hablar sobre "desarrollo ágil" o afirmar que está aplicando una "metodología ágil" si la base de código en la que está trabajando tiene una cobertura de prueba de unidad de 0%? (Y usted, como equipo, no está haciendo nada al respecto).

Para que quede claro: para mí no tiene sentido. En mi experiencia personal, descubrí que las pruebas unitarias son la única herramienta que le permite ser realmente "ágil" (es decir, responder a los cambios, mejorar su diseño, compartir conocimientos, etc.) y TDD es la única práctica que lo lleva allí .

Tal vez hay otras formas, pero todavía no puedo ver cómo pueden funcionar.

Para ser pedante, nada en el Manifiesto Ágil o la Guía Scrum hace referencia alguna a las prácticas técnicas, como las pruebas unitarias o TDD, en absoluto. Entonces, sí, en teoría, podría entregar temprano y, a menudo, con un enfoque en la colaboración y el valor sin ellos y llamarse Ágil, incluso podría tener agilidad .

Sin embargo, en la práctica, es casi imposible entregar valor constantemente ( en producción ) cada pocas semanas sin un buen conjunto de pruebas. Esto incluye pruebas de integración, así como pruebas unitarias. Las pruebas unitarias solo llegan hasta cierto punto. Hay una razón por la cual es una pirámide y no un rectángulo después de todo.

Sin las pruebas como una red de seguridad, introducirá muchos errores de regresión en cada versión, o tendrá miedo de refactorizar. Ambos tendrán un gran impacto en su capacidad para continuar a un ritmo sostenible . Si no puede mantener su ritmo o cambiar el rumbo (rediseño) cuando sea necesario, entonces no tiene agilidad. La agilidad, después de todo, es el objetivo por el que nos esforzamos.

El manifiesto ágil simplemente afirma:

Individuos e interacciones sobre procesos y herramientas.

Software de trabajo sobre documentación completa

Colaboración del cliente sobre negociación de contrato

Responder al cambio sobre seguir un plan

No se mencionan las pruebas unitarias allí. Incluso los 12 principios no mencionan las pruebas.

Entonces, técnicamente, es posible ser un equipo ágil sin escribir pruebas unitarias. Sin embargo, en la práctica, es realmente difícil ver cómo un equipo puede mantener el software en funcionamiento en un entorno ágil sin pruebas para ayudarlos a realizar cambios constantes.

A pesar de que no hay una palabra directa que indique sobre pruebas unitarias o TDD o cualquier tipo de prueba en el manifiesto ágil como otros han respondido aquí, creo que un buen Scrum Master o Desarrollador podría discernir una de las declaraciones en el manifiesto.

Software de trabajo  sobre documentación completa.

¿Cómo sabría alguien si el software funciona? El manifiesto no necesita indicar explícitamente el término prueba. Es sucinto.

Las pruebas unitarias (en el contexto del tema) harán que su fase de codificación sea lenta en la etapa anterior, pero valdrá la pena a medida que avance, haciendo que el desarrollo sea mucho más rápido en adelante. Le brinda un control de grano fino en las pruebas de nivel de código, así como también hace que su diseño sea escalable, lo que le brinda la confianza de que su software está funcionando y puede manejar fácilmente la regresión; a lo que agilizaría su desarrollo.

Tiene absolutamente sentido. Agile no se trata de pruebas, como ya han mencionado otros, sino de responder específicamente a su pregunta:

No, no necesita pruebas unitarias en absoluto.

Puede ejecutar un proceso ágil solo con pruebas de integración. Puede ejecutar una prueba de integración automatizada todas las noches, por ejemplo, y corregir errores que se encuentran al día siguiente. Si lo desea, puede hacer que un probador manual ejecute pruebas de integración continuamente. Independientemente del sistema, las pruebas unitarias son completamente opcionales.

Es posible que las pruebas unitarias lo ayuden a desarrollarse, y lo suficientemente justo para eso, pero hay muchas cosas que pueden ayudar al desarrollo que quizás no tenga.

Sin embargo, necesita alguna forma de prueba, incluso si se trata de los antiguos 'probadores beta del cliente'. Si su cliente está muy involucrado en el proceso y no le importa encontrar errores, entonces esto puede funcionar, ¡ya que tienden a encontrar errores que nadie más pensó que fueran errores!

No es requerido Las pruebas son excelentes cuando tienes personas que realmente saben cómo usarlas. Cuando no lo hace, no solo no es necesario, se convierte en una responsabilidad. Yo diría que hay muchos programadores que no son muy hábiles en eso.

Me alegra que hayas reconocido en tu pregunta que ser ágil se trata de cómo realmente lanzas el software en lugar de seguir alguna metodología. El Manifiesto Ágil es una buena referencia, pero no es la guía definitiva. Ágil existió antes de que existiera. Hay formas de desarrollar software para ser "más ágil", pero se pueden usar diferentes combinaciones en varios proyectos.

Si está lanzando un nuevo software a un ritmo aceptable para el cliente, probablemente sea ágil. También incluiría no tener demasiado retroceso y quejarme de los cambios en las características por parte de los desarrolladores. Arreglar una cosa solo para romper otra tampoco es ideal. Cuando sus usuarios tienen varias versiones de retraso en la actualización, probablemente no sea muy ágil, ya sea que pruebe o no.

Me gustaría contrarrestar el argumento (otras respuestas) de que el manifiesto Ágil establece claramente algo sobre esto, a saber:

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

Me gusta mucho la definición de excelencia técnica de LeSS e incluye pruebas unitarias y TDD. Ahora puede argumentar que es posible que no necesite pruebas unitarias o TDD para lograr esto, pero es la forma más común y probablemente recomendada.

La agilidad organizacional está limitada por la agilidad técnica

En otras palabras, cuando tarda en realizar cambios en su producto, no importa cómo estructura sus equipos, su organización o qué marco adopta, será lento para responder a los cambios.

Si puede evitar que su producto se resista al cambio de otra manera, podría estar en el camino correcto, pero:

Inventé la programación extrema para hacer que el mundo sea seguro para los programadores. - Kent Beck

Scrum carece de prácticas técnicas, pero Jeff dijo lo siguiente al respecto:

Nunca había visto un equipo Scrum hiperproductivo que no utilizara prácticas de desarrollo de Programación Extrema. - Jeff Sutherland

Citado de este artículo: http://ronjeffries.com/articles/017-02ff/gathering2017/

Esperaría que los equipos Scrum sin prácticas técnicas eventualmente mediante el uso de retrospectivas presenten una práctica similar. ¿También quieres ser hiperproductivo?

El modelo de fluencia ágil , lo menciona en el nivel de dos estrellas:

Las técnicas útiles incluyen integración continua, desarrollo basado en pruebas , programación de pares y propiedad colectiva.

Si apunta solo al primer nivel de fluidez ágil, podría saltear la práctica, pero cualquier producto más grande y de mayor duración debería intentar al menos alcanzar un nivel de dos estrellas.

Entonces, el consenso general es que sí, sin buenas pruebas de unidad, código limpio y prácticas de refactorización, actualmente no es posible ser verdaderamente ágil. Esto podría cambiar en el futuro a medida que surjan nuevas prácticas técnicas.

¿Cuál cree que sería la respuesta si le preguntamos a algunos firmantes del manifiesto como Robert C. Martin, Martin Fowler o Kent Beck? Tal vez dirán que depende, pero en general es algo que debes hacer.