La deuda de especificación no desaparece cuando la corriges. Se migra.

Corregir un problema no siempre lo elimina. A veces, simplemente lo mueves a otro lugar.

Recientemente realicé una auditoría de un proyecto para encontrar deuda de especificación. Se trata de lagunas en las instrucciones que provocan errores o un mal comportamiento de la IA. Corregí siete elementos específicos. Tras las correcciones, las pruebas pasaron. Todo parecía estar en verde.

Pero la deuda no desapareció. Migró de los archivos de características (feature files) a las definiciones de pasos (step definitions).

Esto es lo que aprendí al corregir estos elementos:

  • La precisión importa. En lugar de decir "la respuesta es rápida", di "la respuesta se devuelve en menos de 12 segundos tras el envío del pedido". Esto ancla el tiempo.
  • Evita la ambigüedad. "Reintentado 2 veces" no es claro. ¿Significa eso 2 intentos en total o 3? Usa "no más de 2 solicitudes de cargo en total" para estar seguro.
  • Nombra el mecanismo. Decir "el inventario se libera" es vago. Especifica que "el servicio de inventario recibe una solicitud de liberación para el artículo X".
  • Elimina las falsas garantías. Si un paso pasa porque una funcionalidad aún no existe, elimina el paso. Una prueba que pasa para un flujo inexistente es una mentira.
  • Define qué es "correcto". Nunca uses palabras como "correcto" o "adecuado" sin valores concretos. Usa "contiene el order_id 123" en lugar de "contiene el id correcto".

He construido un marco de trabajo (framework) para encontrar estos problemas. Haz estas cinco preguntas para cada escenario:

  • ¿Quién es el responsable de este escenario?
  • ¿Qué decisiones deja esto abiertas?
  • ¿Están todos los términos definidos aquí?
  • ¿Describe esto el comportamiento o la implementación?
  • ¿Qué falta en esta descripción?

La mayor trampa es la brecha entre el texto y el código. Puedes escribir una instrucción perfecta y precisa en tu especificación. Pero si tu código subyacente utiliza un atajo para pasar esa prueba, sigues teniendo deuda.

La especificación dice "crear un pedido a través de la API". En realidad, el código simplemente inyecta un pedido directamente en una base de datos para ahorrar tiempo. La prueba pasa, pero la deuda se trasladó del requisito a la implementación.

No intentes escribir especificaciones perfectas a la primera. Escríbelas, audítalas y corrígelas.

Fuente: https://dev.to/diyaburman/spec-debt-doesnt-disappear-when-you-fix-it-it-migrates-d25

Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi