Issu d'une formation en analyse et en science des données, je considérais l'écriture de tests comme quelque chose de douloureux. Je savais que c'était important, mais je ne savais jamais par où commencer et j'ai toujours tergiversé jusqu'à la fin du projet. Quoi de plus ennuyeux que de tester un morceau de code qui fonctionne déjà ?

Récemment, j'ai commencé à voir les choses à l'envers. J'ai découvert le Test-Driven Development : écrivez vos tests avant de coder réellement la partie fonctionnelle du code. C'est une bonne pratique en génie logiciel qui mériterait d'être appliquée plus souvent aux projets de science des données.

Qu'est-ce que le Test-Driven Development (TDD) ?

Une façon simple de le dire est d'utiliser le framework Red/Green/Refactor . Chaque fois que vous souhaitez ajouter des fonctionnalités au code, vous pouvez suivre un cycle en trois étapes :

1. Rouge . Créez un test qui échoue. c'est-à-dire écrire les besoins fonctionnels de votre code
2. Vert . Écrivez le code de production qui fait passer le test. c'est-à-dire répondre aux besoins fonctionnels du code
3. Refactoriser. Nettoyez le désordre que vous venez de créer. c'est-à-dire nettoyer votre code sans changer la fonctionnalité

Illustrons cela par un exemple concret. En tant qu'étape de post-traitement d'un projet de reconnaissance d'entité nommée , nous souhaitons créer une fonction de traitement pour extraire l'unité de durée (jour/semaine/mois/..) et la valeur de durée dans un texte.

1. Écrivons un test unitaire qui répond aux besoins fonctionnels et une fonction vide.

2. Nous écrivons du code qui réussit le test.

Le test est VERT Hourra !! Attends... on est sûr que c'est SEC, SOLIDE, pep8 ??

3. Nous refactorisons la fonction, pour garantir les meilleures pratiques de codage.

Ici, nous avons ajouté des annotations de type, créé une fonction générique pour convertir le nombre de lettres en flottant (avec son propre test unitaire également) et refactorisé la façon dont nous remplissons le dictionnaire.

Où pouvons-nous appliquer le développement piloté par les tests en science des données ?

Le Test Driven Development n'est pas pertinent à chaque étape d'un projet de science des données. Par exemple, cela n'en vaut pas la peine lors d' explorations de données ou de modèles où vous n'êtes pas sûr de ce que vous recherchez : écrire des tests sans connaître la sortie attendue est probablement exagéré.

Il devient très utile chaque fois que vous avez besoin de construire des pipelines de production robustes .

Dans ce contexte, nous devons mettre en place plusieurs types de tests :

• Tests unitaires : un test pour chaque morceau de code du projet
• Tests sur modèle : assurez-vous que le modèle a de bonnes performances et se comporte correctement
• Tests d'intégration : s'assurer qu'il y a un bon lien entre chaque morceau de code

Pour les tests sur modèle , il doit être utilisé avec précaution. Lorsqu'il s'agit de modèles prédictifs, nous traitons d' incertitude . En effet, de nombreux algorithmes d'apprentissage automatique sont intrinsèquement aléatoires - plusieurs exécutions utilisant les mêmes entrées peuvent produire des résultats légèrement différents à chaque fois. Cela peut conduire à des tests floconneux : un test qui parfois réussit et parfois échoue malgré aucune modification du code ou du test lui-même. Si nous sommes trop précis sur les cas de test lors d'un premier développement piloté par les tests, il est fort probable que certains tests se cassent lors d'une prochaine itération. Un nouveau modèle pourrait se comporter différemment dans certains cas, tout en étant globalement plus performant. Par conséquent, il est préférable d'inclure dans les tests de modèle uniquement les cas de base nécessaires au projet.

Enfin pour les tests d'intégration , il s'applique bien aux morceaux de code qui n'incluent pas les prédictions du modèle. S'il inclut la prédiction du modèle, il est préférable de tester le format de la sortie plutôt que la sortie réelle.

Une bonne pratique consiste à inclure ces tests dans le CI/CD de votre projet. Par conséquent, chaque fois qu'une nouvelle proposition de fonctionnalité est faite, il est garanti qu'aucune autre fonctionnalité n'est interrompue.

Pourquoi change-t-il la donne ?

L'adoption du développement piloté par les tests change vraiment la façon dont vous organisez vos sessions de codage et présente de nombreux avantages :

• Il valide instantanément les spécifications métiers et techniques . C'est aussi une excellente documentation pour un data scientist qui découvre le projet et a besoin de comprendre comment le projet fonctionne.
• Cela donne confiance dans le code . Chaque cas d'utilisation est couvert par un test et vous ou vos coéquipiers pouvez ajouter des fonctionnalités supplémentaires sans craindre de casser tout ce qui a déjà été fait.
• C'est un gain de temps . On peut y voir quelque chose qui ralentit le développement. Mais ce n'est pas le cas, cela oblige à réfléchir en amont aux besoins fonctionnels et à anticiper les cas extrêmes. Croyez-moi, en fin de compte, cela permet d'économiser beaucoup de temps de débogage et d'itération.
• Cela rend même le développement plus amusant ! Il décompose le code en petits défis de résolution de problèmes. Et c'est un ajustement parfait pour le codage par les pairs.