Desarrollo de versión y control de prueba

Question

El proceso estándar para el desarrollo basado en pruebas parece ser agregar una prueba, verla fallar, escribir código de producción, ver el pase de prueba, refactorizar y verificar todo en control de fuente.

¿Hay algo que le permita verificar la revisión x del código de prueba, y la revisión x-1 del código de producción, y ver que las pruebas que ha escrito en la revisión x fallan? (Me interesaría cualquier idioma y sistema de control de fuente, pero uso ruby ​​y git)

Puede haber circunstancias en las que podría agregar pruebas que ya pasen, pero serían más una verificación que un desarrollo.

Answer 1

Un par de cosas:

1. Después de refactorización la prueba, se ejecuta la prueba de nuevo
2. A continuación, refactorizar el código, a continuación, ejecute la prueba de nuevo
3. Entonces, usted no tiene para el registro de inmediato, pero se podía

en TDD, no hay ningún propósito en la adición de una prueba que pasa. Es una pérdida de tiempo. He tenido la tentación de hacer esto para aumentar la cobertura del código, pero ese código debería haber sido cubierto por pruebas que realmente fallaban primero.

Si la prueba no falla primero, entonces no sabe si el código que luego agrega soluciona el problema, y ​​no sabe si la prueba realmente prueba algo. Ya no es una prueba - es solo un código que puede o no probar cualquier cosa.

Answer 2

Si mantiene el código de producción y prueba en las áreas de versiones separadas (por ejemplo, proyectos/árboles fuente/bibliotecas/etc.), la mayoría de los sistemas de control de versiones le permiten consultar versiones anteriores del código y reconstruirlas. En su caso, podría verificar la versión x-1 del código de producción, reconstruirlo y luego ejecutar el código de prueba contra la implementación desplegable/recién desarrollada.

Una cosa que podría ayudar sería etiquetar/etiquetar todo su código cuando hace un lanzamiento, para que pueda buscar fácilmente un árbol fuente completo para una versión anterior de su código.

Answer 3

¿Hay algo que le permite la salida x revisión del código de prueba, y la revisión x-1 del código de producción , y ver que las pruebas que has escrito en la revisión x fallan?

Creo que está buscando la palabra clave integración continua. Hay muchas herramientas que realmente se implementan como enganches post-commit en los sistemas de control de versiones (también conocido como algo que se ejecuta en los servidores/repositorio central después de cada confirmación): por ejemplo, ejecutarán las pruebas unitarias después de cada commit y enviarán un correo electrónico a los committers si una revisión introduce una regresión.

Estas herramientas son perfectamente capaces de detectar qué pruebas son nueva y nunca pasó de viejos pruebas que solían pasar y que actualmente fallan debido a una reciente cometer, lo que significa que el uso de TDD y la integración continua en conjunto es sólo bien: probablemente podrá configurar sus herramientas para no gritar cuando se presente una nueva prueba de falla y quejarse solo en regresiones.

Como siempre, lo dirigiré a Wikipedia para un generic introduction on the topic. Y un recurso más detallado, bastante famoso sería el artículo de Martin Fowler

Answer 4

Simplemente mantenga sus pruebas y códigos en directorios separados, y luego puede ver una versión de las pruebas y otra del código.

Dicho esto, en un entorno multiproveedor, generalmente no quiere que se compruebe el código donde fallan las pruebas.

¿También cuestionaría la motivación para hacer esto? Si se trata de "hacer cumplir" la prueba que falla primero, entonces le señalaría this comment del padre de (la promoción de) TDD.

Answer 5

"Puede haber circunstancias en las que podría agregar pruebas que ya pasen, pero serían más una verificación que un desarrollo".

En TDD usted siempre Vea una falla de prueba antes de hacerla pasar para que sepa que funciona.

Como has encontrado, a veces quieres describir explícitamente el comportamiento que está cubierto por el código que ya has escrito pero cuando se considera desde fuera la clase bajo prueba es una característica separada de la clase. En ese caso, la prueba pasará.

Pero, siga viendo la prueba fallar.

Escriba la prueba con una aserción que obviamente no funciona y luego corrija la afirmación para que pase. O bien, rompa temporalmente el código y observe todas las pruebas afectadas, incluida la nueva. Y luego arregle el código para que funcione de nuevo.

Answer 6

Si git commit después de escribir sus pruebas fallidas, y nuevamente cuando están pasando, debe poder crear una rama más adelante en el punto donde las pruebas fallan.

Puede agregar más pruebas, verificar que también fallen, git commit, git merge y luego ejecutar las pruebas con la base de código actual para ver si el trabajo que ya realizó hará que la prueba pase o si necesita ahora hacer un poco más de trabajo.