Rendre les tests plus performants

[bonjourmauko]

Improve performance for developers

Pour les dévs

Story :

Quand je contribue à OpenFisca,
J'ai besoin que les tests soient plus rapides,
Pour pouvoir faire du test-driven development.

Definition of done :

Diminuer le temps du test suite de 20%. Cela inclut de possibles tests de performance ajoutés pour pouvoir l'en mesurer.

Example :

Si l'on ajoute un test de performance qui augmente le temps du test suite de 10%, alors le gain de performance doit être de 30%.

• Faire du profiling (temps) pour avoir une idée des pistes - parent Faire du profiling (temps) pour trouver pistes % perf #1014

Pistes :

• Utiliser ruaml.yaml ou PyYaml avec libyaml - parent Utiliser ruaml.yaml ou PyYaml avec libyaml (tests) #1016 (6,72%)
• Pas de vérifications sur entités/périodes en mode test - parent Pas de vérifications sur entités/périodes en mode test #1033
• Do type checking at compile time - parent Do type checking at compile time openfisca-core#690
• Regrouper les test YAML dans une seule run OpenFisca - parent Group YAML tests in a single OpenFisca run to speed up testing time openfisca-core#616
  • mette tout dans un seul fichier
  • charcher une seule fois
  • vectoriser les tests
• Faster load/startup in debug/dev/test mode - parent Faster load/startup in debug/dev/test mode openfisca-core#535

Autres pistes :

• Pre-fetch YAML et build simulations avant de lancer les tests
• TaxBenefitSystem : memoiser les paramètres le temps d'un test suite run (pas reload paramètres)
• TaxBenefitSystem : memoiser les variables le temps d'un test suite run (pas reload variables)
• Séparer les tests entre unitaires python ; intégration python ; et intégration API JSON
• Factoriser les tests similaires pour les lancer dans un seul scénario

[Morendil]

@maukoquiroga Je ne comprends pas pourquoi cette issue est sur France, que peut-on faire au niveau de France ? Est-ce que je peux fermer en ouvrant au besoin une issue sur Core ?

[bonjourmauko]

@Morendil Parce que :

• c'est une issue essentiellement d'OpenFisca-France, dont quelques mais pas toutes les pistes de solution engagement des changements sur core.

• la douleur de l'utilisateur reside sur France, pas sur core.

Le problème sur core, tel que ci-décris, n'existe pas.

[Morendil]

Je dirais l'inverse:

c'est une issue essentiellement d'OpenFisca-France, dont quelques mais pas toutes les pistes de solution engagement des changements sur France.

En effet, j'estime informellement que le nombre de tests YAML sur France augmente de façon constante et très significative (comment l'objectiver est une question à part entière). Cette inflation du nombre de tests a déjà largement annulé les gains de performance de 20% qu'aurait apporté la résolution de cette issue selon sa Definition of Done. Or ces gains ne sont pas encore réalisés…

Pour moi le problème est putôt "on a trop de tests et pas assez de questionnement sur le ROI de chaque test". Les solutions ne sont pas techniques, elles sont humaines: sensibiliser les contributeurs à cette question, et leur transmettre les compétences nécessaires à évaluer le ROI de chaque test.

Je propose qu'on mette en pause ces travaux d'optimisation par la voie technique et qu'on lise ensemble en atelier un certain nombre de tests en posant la question de leur valeur, dans l'esprit d'un Gemba walk.

[bonjourmauko]

Hello @Morendil,

Sauf erreur de ma part,

c'est une issue essentiellement d'OpenFisca-France, dont quelques mais pas toutes les pistes de solution engagement des changements sur core.

et

c'est une issue essentiellement d'OpenFisca-France, dont quelques mais pas toutes les pistes de solution engagement des changements sur France.

sont équivalentes 😄

En effet, j'estime informellement que le nombre de tests YAML sur France augmente de façon constante et très significative.

Même impression. Et je ne suis pas sûr que l'on teste de façon très réfléchie.

Comment l'objectiver est une question à part entière

L'objectivation à mon avis va dépendre à chaque fois de ta story, du job-to-be-done de l'utilisateur concerné par le problème en question.

Ici, il s'agit de pouvoir mieux faire du TDD, le 20% d'amélioration n'étant qu'une des formes possible de l'objectiver.

Changer radicalement la façon comment on conçoit les tests sur OpenFisca-France doit être objectivé par rapport à son objectif identifié au préalable.

Par exemple, si l'on envisage cette initiative comment venant à résoudre le problème ci-décrit, alors sont objectivation est celle ci-décrite.

Pour moi le problème est plutôt "on a trop de tests et pas assez de questionnement sur le ROI de chaque test". Les solutions ne sont pas techniques, elles sont humaines: sensibiliser les contributeurs à cette question, et leur transmettre les compétences nécessaires à évaluer le ROI de chaque test.

Je suis convaincu comme toi que l'innovation de rupture viendra d'une meilleure qualité du testing et pas d'une sur-optimisation en C du code vectoriel.

Je propose qu'on mette en pause ces travaux d'optimisation par la voie technique.

Ils sont déjà en pause (il n'y a personne dans l'assignees).

Et qu'on lise ensemble en atelier un certain nombre de tests en posant la question de leur valeur, dans l'esprit d'un Gemba walk.

Le définition of done n'est jamais technique, c'est plutôt un objectif d'impact du point de vue de l'utilisateur.

On ne peut pas prescrire la solution en même temps que l'on définit le problème, ça va à l'encontre du principe d'autonomie :

Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.

En essayant de garder l'esprit du delivery, c'est-a-dire du consentement over consensus, il me semble que le nouveau format de RFC est parfait pour répondre à cette type d'issue, qui est très précise sur le problème et très vague sur l'implementation des possibles solutions (et cela intentionnellement).

Si tu as un peu de slack je t'invite à t'assigner l'issue et à organiser l'atelier pour voir ce que cela donne, toujours en gardant la main sur l'objectif et le CTA 😃. Sinon attendons un peu à que quelqu'un d'autre fasse pareil, toujours à risque que sa solution ne soit pas la même que celle que tu envisages.

[Morendil]

Suite à nos discussions IRL, l'état de cette issue est le suivant: nous avons surtout l'intention d'intervenir sur le flux entrant de nouveaux tests. Nous serons par exemple plus exigeants sur le fait que chaque nouveau test justifie son existence en vérifiant quelque chose qui n'est pas déjà amplement testé par ailleurs. Ainsi il n'est pas utile de tester une modification ne consistant qu'en la revalorisation d'un paramètre législatif, à l'exclusion de toute évolution structurelle de la loi. Nous n'allons pas investir à court terme d'énergie et de temps sur le stock. Je garde en tête l'idée de l'atelier évoqué ci-dessus mais ce n'est pas une priorité.