Tests classif update - Githubissues

ecotaxa / ecotaxa_back

Backend of the EcoTaxa application

GNU General Public License v3.0

6 stars 5 forks source link

Tests classif update #54

Closed emmaamblard closed 1 year ago

emmaamblard commented 1 year ago

J'ai ajouté les tests dont on avait parlé, notamment :

re-prédire des objets prédits avec la même classe, mais en changeant le score
faire un reset_to_predicted sur des objets validés
quelques tests sur le revert (un revert après validation, un 2nd revert immédiatement après qui ne change rien, puis un revert après le reset_to_predicted)
un test sur la gestion des résultats de ML au mauvais format (avec des listes de tailles différentes pour les scores et les classifications, des champs à None et des scores en dehors de [0, 1]).

Ils mériteraient peut-être d'être encore complétés, mais j'ouvre déjà la pull request pour que ce soit plus simple d'en discuter.

grololo06 commented 1 year ago

So far so good! A la fin du 'tox' il y a une génération de couverture de tests, i.e. on mesure le code qui est atteint pendant les tests auto. Je t'invite à y jeter un œil pour voir où porter l'effort. Comme prévu, la couverture n'est pas fabuleuse sur tout ce qui est relatif à la classification auto. Ici, 2 cas: le répertoire ML lui-même, qu'on a +/- décidé d'ignorer, et le reste. E.g., peut-être d'intérêt dans notre cas, py/BO/Prediction.py. N'hésite pas à corriger ou rajouter des commentaires dans le code testé, j'ai du mal à croire que j'ai tout bien expliqué!

emmaamblard commented 1 year ago

@grololo06 Effectivement aucune des fonctions dans BO/Prediction.py n'étaient testées, donc j'ai ajouté des tests pour cette partie. Juste, il n'y avait pas de points d'entrée existants pour ces fonctions dans l'API, est-ce que ce serait mieux de les faire (et d'adapter les tests en conséquence) ?

grololo06 commented 1 year ago

@grololo06 Effectivement aucune des fonctions dans BO/Prediction.py n'étaient testées, donc j'ai ajouté des tests pour cette partie. Juste, il n'y avait pas de points d'entrée existants pour ces fonctions dans l'API, est-ce que ce serait mieux de les faire (et d'adapter les tests en conséquence) ?

Non, pas besoin. Généralement on essaie d'inclure le max. de code dans les tests, et historiquement j'ai eu des soucis avec la validation pydantic en passant par les points d'entrée, donc beaucoup de tests sont basés sur cette méthode. Du coup ils peuvent aussi servir d'exemple aux utilisateurs de l'API (e.g. https://github.com/ecotaxa/ecotaxa_back/commit/a0f96d91067571e486dfb8d8d3e68e26442a26c9 pour le petit gestionnaire de fichiers intégré). Mais les services sont faits pour être testables donc ton test est OK.