Viniendo de un fondo de análisis y ciencia de datos, solía ver escribir pruebas como algo doloroso. Sabía que era importante, pero nunca sabía por dónde empezar y siempre postergaba hasta el final del proyecto. ¿Qué es más aburrido que probar un fragmento de código que ya funciona?

Recientemente, comencé a ver las cosas al revés. Descubrí el desarrollo basado en pruebas: escribe tus pruebas antes de codificar la parte funcional del código. Es una mejor práctica en ingeniería de software que merece ser aplicada más a menudo a proyectos de ciencia de datos.

¿Qué es el desarrollo guiado por pruebas (TDD)?

Una forma simple de expresarlo es a través del marco Red/Green/Refactor . Cada vez que desee agregar funcionalidad al código, puede seguir un ciclo de tres pasos:

1. rojo _ Cree una prueba que falle. es decir, escriba las necesidades funcionales de su código
2. verde _ Escriba el código de producción que hace que la prueba pase. es decir, cumplir con las necesidades funcionales del código
3. Refactorizar. Limpia el desastre que acabas de hacer. es decir, limpia tu código sin cambiar la funcionalidad

Ilustremos esto con un ejemplo de la vida real. Como paso de posprocesamiento para un proyecto de reconocimiento de entidad nombrada , queremos crear una función de procesamiento para extraer la unidad de duración (día/semana/mes/..) y el valor de duración en un texto.

1. Escribamos una prueba unitaria que satisfaga las necesidades funcionales y una función vacía.

2. Escribimos código que pasa la prueba.

La prueba es VERDE Hurra!! Espera... ¿estamos seguros de que es SECO, SÓLIDO, pep8?

3. Refactorizamos la función para garantizar las mejores prácticas de codificación.

Aquí agregamos anotaciones de tipo, creamos una función genérica para convertir el número de letra en flotante (también con su propia prueba unitaria) y refactorizamos cómo llenamos el diccionario.

¿Dónde podemos aplicar Test-Driven Development en Data Science?

El desarrollo basado en pruebas no es relevante en cada paso de un proyecto de ciencia de datos. Por ejemplo, no vale la pena durante las exploraciones de datos o modelos en las que no está seguro de lo que está buscando: escribir pruebas sin saber el resultado esperado probablemente sea excesivo.

Se vuelve muy útil siempre que necesite construir canales de producción robustos .

En este contexto, necesitamos implementar varios tipos de pruebas:

• Pruebas unitarias: una prueba para cada pieza de código del proyecto
• Pruebas de modelo : asegurarse de que el modelo tiene un buen rendimiento y se comporta correctamente
• Pruebas de integración : asegurando que haya un buen enlace entre cada pieza de código

Para pruebas de modelos , debe usarse con cuidado. Cuando se trata de modelos predictivos, se trata de incertidumbre . De hecho, muchos algoritmos de aprendizaje automático son inherentemente aleatorios: varias ejecuciones con las mismas entradas pueden producir resultados ligeramente diferentes cada vez. Esto puede dar lugar a pruebas inestables : una prueba que a veces pasa y otras veces falla a pesar de que no haya cambios en el código o en la prueba en sí. Si somos demasiado específicos en los casos de prueba durante un primer desarrollo basado en pruebas, es muy probable que algunas pruebas se rompan en la siguiente iteración. Un nuevo modelo podría comportarse de manera diferente en algunos casos, mientras se desempeña mejor a nivel mundial. Por lo tanto, es mejor incluir en las pruebas del modelo solo los casos básicos que son necesarios para el proyecto.

Por último, para las pruebas de integración , se aplica bien a fragmentos de código que no incluyen predicciones del modelo. Si incluye la predicción del modelo, es mejor probar el formato de la salida que la salida real.

Una buena práctica es incluir esas pruebas en el CI/CD de su proyecto. Por lo tanto, cada vez que se hace una propuesta de nueva funcionalidad, se asegura que ninguna otra funcionalidad se rompa.

¿Por qué es un cambio de juego?

Adoptar el desarrollo basado en pruebas realmente cambia la forma en que organiza sus sesiones de codificación y tiene muchos beneficios:

• Valida instantáneamente las especificaciones comerciales y técnicas . También es una excelente documentación para un científico de datos que descubre el proyecto y necesita comprender cómo funciona el proyecto.
• Da confianza en el código . Cada caso de uso está cubierto por una prueba y usted o sus compañeros de equipo pueden agregar funcionalidades adicionales sin temor a romper nada de lo que ya se ha hecho.
• Es ahorro de tiempo . Uno puede verlo como algo que está ralentizando el desarrollo. Pero no lo es, te obliga a pensar de antemano en las necesidades funcionales y anticiparte a los casos extremos. Créame, al final del día, ahorra mucho tiempo de depuración e iteración.
• ¡Incluso hace que el desarrollo sea más divertido ! Descompone el código en pequeños desafíos de resolución de problemas. Y es perfecto para la codificación entre pares.