Utilise PyTest

[bonjourmauko]

Depends on openfisca/openfisca-core#746

• Amélioration technique
• Détails :
  • Permet d'utiliser pytest pour faire tourner les tests.
  • La librairie actuelle, nose, n'est plus en développement actif.

---

Ces changements (effacez les lignes ne correspondant pas à votre cas) :

• Modifient des éléments non fonctionnels de ce dépôt.

---

Quelques conseils à prendre en compte :

• Jetez un coup d'œil au guide de contribution.
• Regardez s'il n'y a pas une proposition introduisant ces mêmes changements.
• Documentez votre contribution avec des références législatives.
• Mettez à jour ou ajoutez des tests correspondant à votre contribution.
• Augmentez le numéro de version dans setup.py.
• Mettez à jour le CHANGELOG.md.
• Assurez-vous de bien décrire votre contribution, comme indiqué ci-dessus

[Morendil]

PyTest est cool. J'ai esquissé un petit script pour remplacer openfisca-run-tests. Ce n'est pas une réimplémentation iso, ça fait moins de choses, mais c'est suffisant pour la CI et ça nous permettrait de nous débarrasser de nose dans Core. PR dans la semaine peut-être.

Ce qui est vraiment bien c'est pytest.approx qui fait la même chose que assert_near mais en mieux, et qui supporte Numpy out of the box. Le seul KO pour l'instant est sur les énumérations.

[fpagnoux]

PyTest est cool. J'ai esquissé un petit script pour remplacer openfisca-run-tests. Ce n'est pas une réimplémentation iso, ça fait moins de choses, mais c'est suffisant pour la CI et ça nous permettrait de nous débarrasser de nose dans Core. PR dans la semaine peut-être.

Attention, il y a un autre sujet actif sur les tests inscrit dans la planif. Ce n'est à 100% le même sujet (format vs moteur d'exécution) mais il y a des recoupements et de gros risques de conflits.

Sur le fond:

• Si réécriture non-iso, il va falloir faire attention à ne pas supprimer des features qui sont activement utilisées. Elles sont souvent issues de demandes explicites. Mais il y a sans-doute du tri à faire (je ne suis pas sûr que --name_filter soit très utile)
• Il est aussi important que ça reste un outil partagé et offert par Core, donc utilisable indépendamment de la localisation des tests ou autres spécificités d'un modèle en particulier.
• Sauf preuve que faire l'inverse ne dégrade pas les performances, il faut a priori lire et exécuter les tests à la volée, et ne pas tout charger en mémoire upfront.

[Morendil]

@fpagnoux Je voyais ça comme un remplaçant "drop-in" de openfisca-run-tests. Les questions de format sont entièrement orthogonales (traitées via scenarios.make_json_or_python_to_test).

Sur des essais informels, charger tous les YAML up-front ne pose aucun problème, et permet de décompter le nombre de tests et contrôler la granularité d'exécution mieux que ne semblait le faire le runner nose. Quel souci anticiperais-tu en termes de performance ?

[sandcha]

Et mettre à jour le README.md qui référence encore nosetests?

[fpagnoux]

Les questions de format sont entièrement orthogonales (traitées via scenarios.make_json_or_python_to_test).

Pas totalement, vu que:

• on veut pas dépendre des scenarios (et de biryani) pour le parsing des tests. Il faudra donc appeler une autre fonction, avec une signature possiblement différente.
• des changements sur la structure des outputs attendus peuvent changer un peu le code du test runner

[Morendil]

Up ? Est-ce que tes réserves sont levées @fpagnoux ?

[pblayo]

Il faut changer le numéro de version je pense :
Version 27.1.1 already exists in commit:
commit 8290f34

[bonjourmauko]

Il faut changer le numéro de version

@pblayo Fait !

Et mettre à jour le README.md qui référence encore nosetests?

Fait !

Il est aussi important que ça reste un outil partagé et offert par Core, donc utilisable indépendamment de la localisation des tests ou autres spécificités d'un modèle en particulier.

Ces changements ne touchent pas openfisca-run-test, qui continue à utiliser nose.