Un mantenedor de dupehound, detector de código duplicado de código abierto, plantea en Hacker News un problema clásico del análisis estático: las herramientas que buscan duplicaciones estructurales también marcan como repetido el código que aparece de forma intencionada en los tests, donde repetir escenarios es la práctica habitual y recomendada. Para un detector estructural no hay forma inmediata de saber si una repetición es un antipatrón que conviene eliminar o una parte legítima de la suite de pruebas.
El autor explica que la solución naïve de eliminar los duplicados destruiría precisamente lo que los tests necesitan reproducir: variaciones del mismo escenario para validar distintos casos. La vía que propone sigue el modelo de los linters: una configuración por defecto sin intervención del usuario que funcione bien en la mayoría de casos, combinada con un mecanismo de aceptación manual en el que el desarrollador pueda marcar una repetición como «intencional» para que la herramienta la ignore en futuros análisis. Se trata, en la práctica, de un modelo humano en el bucle.
El hilo está abierto a la comunidad en busca de alternativas: desde filtros por directorio o por convenciones de nombrado que separen tests del resto del código, hasta heurísticas que distingan las repeticiones propias de los frameworks de testing de las duplicaciones accidentales en el código de producción. El debate toca un punto más general del desarrollo de herramientas de calidad de código: cómo lograr que la automatización aplique el contexto que hoy solo conoce quien programa.