He estado en numerosos equipos que intentan practicar metodologías ágiles y, a menudo, estos equipos están centrados en las pruebas. ¿La prueba es una parte necesaria de la práctica de la metodología Agile o es solo una práctica de XP que se ha enganchado a lo largo de los años?

Las pruebas son absolutamente esenciales para agile, principalmente porque agile se basa en mejoras incrementales: la dificultad es que a veces puede ser difícil ver cómo los cambios actuales afectarán su código anterior. La mejor manera de estar seguro de que no ha roto algo es probarlo y saber CÓMO probarlo. De esa manera, encontrará el error de inmediato, no en el futuro, cuando haya olvidado exactamente lo que hizo cuando estaba escribiendo el código que rompió alguna característica antigua.

La razón por la que esto es diferente de la programación de tipo de diseño descendente más tradicional es que en ese entorno es a) muy difícil de probar hasta que tenga el producto terminado b) en teoría está considerando todos los criterios de diseño al mismo tiempo, y por lo tanto, es menos probable que tome una decisión de diseño que rompa las decisiones de diseño anteriores.

Probablemente esté hablando de pruebas automatizadas, pruebas unitarias, pruebas de integración, etc. Estas son más importantes para las pruebas ágiles que las pruebas manuales (con probadores y demás) porque son demasiado lentas, por lo que no es posible probar cada pequeño cambio que realice. Dado que ágil se trata de iteraciones pequeñas y rápidas, es muy útil tener pruebas que verifiquen la corrección en segundos o minutos, en lugar de horas o días.

Si no tiene pruebas, ¿cómo sabe que funciona su código?

Editar: la afirmación de que las pruebas no pueden probar que el código funciona no define un término crucial, a saber, funciona . ¿Qué significa que un programa funcione? Si mantiene este término vago, entonces no hay forma de probar o asegurarse de que algún programa funcione. Siempre.

Por otro lado, puede definir trabajos como "comportamientos según una especificación". Ahora no solo puede usar pruebas para mostrar que el código funciona, sino que las pruebas mismas pueden servir como una especificación ejecutable del comportamiento de su código. En otras palabras, un conjunto de pruebas bien escrito define lo que funciona significa.

Esta forma de pensar también te obliga a volver a examinar el significado de un error . Si su código pasa todas las pruebas, entonces no hay errores en el código. Si, a pesar de eso, el sistema no se comporta como debería, entonces su comportamiento no se especifica correctamente. I. e. El error está en la especificación, definida por las pruebas.

Este enfoque para el desarrollo de software desacopla la especificación funcional de un sistema desde su implementación, lo que, según todos los libros de ingeniería de software del mundo, es algo muy bueno. Al mismo tiempo, este enfoque garantiza que su implementación siempre corresponda a la especificación funcional.

No, no es necesario"

Los principios de Agile no dicen nada directamente sobre las pruebas.

Pero es altamente recomendable

Dado el compromiso de Agile con un proceso sostenible, entrega continua / incremental y calidad de software, las pruebas automatizadas son la mejor solución actualmente disponible para la mayoría de los proyectos

Las excepciones (como señaló Jörg W Mittag) incluyen herramientas de desarrollo probadamente correctas, sistemas de metaprogramación que generan código, et al. Pero este tipo de sistemas son raros.

Tanto Agile como XP intentan evitar Big Design Up Front . En BDUF, se reúnen los requisitos, se crea una especificación formal, a continuación, la codificación se lleva a cabo, a continuación, se hacen las pruebas. Esto tiene sentido para sistemas bien definidos, de misión y de vida crítica como equipos médicos, sondas espaciales, etc.

Agile evita este flujo porque no funciona bien para problemas que no están bien definidos, por ejemplo, "cualquier cambio que el cliente solicite esta semana". Todavía necesitamos una especificación formal, por lo que sabemos qué hacer y cuándo terminamos, pero en lugar de algún tipo de documento escrito, usamos código en forma de pruebas automatizadas.

Las pruebas unitarias automatizadas son rápidas de escribir, rápidas de ejecutar y muy modulares / desacopladas. Esto los convierte en una forma rápida de especificar y verificar formalmente los requisitos.