¿Se han vuelto las pruebas de código (testing) más importantes con IA?
Muchas discusiones recientes en diversas redes sociales se han escrito, con desarrolladores diciendo que leer el código ya no es tan importante como antes, que la IA ahora hace mejor código que cualquier desarrollador Mid y que la prioridad es ahora mayormente lanzar características para el usuario.
Muchos, sin embargo, están de acuerdo en que tener tests en el código es lo que permite que puedan avanzar el desarrollo a mayor velocidad, ya que los tests son los que validarán que las características que se estén programando funcionen de acuerdo con los requerimientos.
Leer o no leer el código
La IA incluso puede generar código erróneo, y el problema puede ser peor si también escribe los tests, porque si intenta conseguir un objetivo, puede hacer que los tests acepten ese código. Como desarrollador, es importante mantener control sobre el código que se está a punto de subir. No se trata de leerlo como si fuera una obra literaria, línea por línea, sino de tener una idea general de lo que está tratando de hacer.
La implementación, conforme pasan los meses, y con la continua mejora de los modelos de programación, se está volviendo la actividad más sencilla. El criterio en cada programador es lo que importa en la actualidad.
Lo que ahora se vuelve importante es: cuando lance esta nueva pieza de código: ¿cuántos usuarios por segundo / minuto tendrá? ¿Estará disponible para todos desde el día uno? ¿Habrá fallas de seguridad que puedan afectar la aplicación?
Criterio y habilidades de planificación. Cada día más importantes.
Las pruebas guiando a los agentes
Antes, escribir pruebas era una excelente manera de evitar romper el código y pasar las largas horas tratando de arreglarlo ante cualquier equivocación. No era el componente principal. He visto muchas aplicaciones exitosas que no tenían una colección de pruebas que ejecutar.
Hasta que los desarrolladores en diversas compañías se dieron cuenta de que tener esas pruebas en el código permite asegurarse de que cualquier flujo alternativo o caso inesperado del proyecto no falle desde el día uno.
Como he hecho en algunos proyectos, escribo manualmente los 3 primeros tests y, eventualmente, el agente aprende mi manera de programar. Aun así, es importante aprender lo que es un mock, lo que es un spy, etc. Y, vaya sorpresa, tener el criterio para saber cuándo usarlo.
Conforme crezca tu equipo, tener pipelines que ejecuten las pruebas de código permitirá que incluso nuevos desarrolladores puedan contribuir desde el día uno.
E2E + Pruebas de integración + Pruebas unitarias
Si tuviera que establecer una prioridad actualmente, empezaría con pruebas desde el punto de vista del producto final o del usuario, e iría bajando progresivamente hacia pruebas más técnicas.
A manera muy general, así es como lo veo actualmente:
¿Necesito que mi código sea probado de la manera más cercana al cliente? Usa end-to-end (E2E). Un navegador ejecutará tus instrucciones para asegurarse de que la experiencia de usuario nunca se interrumpa.
¿Necesito que mi código sea probado a nivel de API? Usa tests de integración. Asegúrate de que usuarios no envíen contenido malicioso a tus APIs. Comprueba que el contenido de los requests sea el que esperabas y, si no lo es, cómo debería responder el sistema.
¿Necesito que mis librerías, programas de líneas de comando (CLI), o plugins que estoy creando sean usados por otros desarrolladores? Utiliza pruebas unitarias. A pesar de ser las más técnicas, son buenas para asegurarse de que un código que es utilizado por muchas otras personas se comporte como se debe.
¿Y lo mejor de todo?
Es que la IA se está volviendo mejor en escribir las pruebas. Si de algún modo puedes escribir para tu agente alguna instrucción para asegurarte de que las pruebas que escribe tengan sentido y tengan la prioridad que expliqué arriba, habrás automatizado gran parte de la labor de escribir pruebas. Pero recuerda por última vez: criterio y lectura.
Hay que saber leer, y con la Inteligencia Artificial, cuándo leer.
