fix: Flacky test causé par un mot de passe aléatoire non valide #1621
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Quoi ?
Les tests échouaient parfois de manière inexpliquée sur la CI, comme ici: https://github.com/gip-inclusion/le-marche/actions/runs/12300147620/job/34327607329
Un autre test échoué est https://github.com/gip-inclusion/le-marche/actions/runs/12548544358/job/34987960701, cette fois à cause des factory avec du Fuzzing. La région était générée aléatoirement, matchant aléatoirement le périmètre créé dans le setup. Par ailleurs, la factory générait des données un peu absurde car le département Morbihan pouvait se trouver dans la région Occitanie sans problèmes.
Des tests interdépendants ont été trouvés en changeant l'ordre d’exécution avec
--shuffle
ou--reverse
. Par exemple,pythonb test --reverse lemarche.tenders.tests.test_commands.TestSendAuthorListOfSuperSiaesEmails
échoue avec l'option reverse.Pourquoi ?
Un mot de passe aléatoire était généré dans les tests, mais dans certains cas il ne respectait pas les caractéristiques requises par le validateur.
Le fait de dépendre des données contenues dans les migrations peut être problématique pour certains tests, notamment les
TransactionTestCase
et ceux qui en héritent car la base est purgée à la fin du test.Pareil, avec des factory ou des objets nommés après des séquences d'id, les séquences ne sont pas toujours prédictibles et il ne faut pas compter dessus. (
test_list_tenders_content
)Comment ?
Ce mot de passe à été remplacé par un mot de passe fixe respectant le validateur. Si le validateur doit être testé ce n'est pas au niveau des tests fonctionnels.
Remarques
Un test qui avait été commenté comme cassé était en fait fonctionnel, il a été de-commenté
Voici le script utilisé pour tester la validité du mot de passe aléatoire:
.copy()
partouttime.sleep()
Les test avec du Fuzzing sont utiles, mais pas pas forcément à leur place dans une CI destinée à valider les changements de code. Par ailleurs ici ils ne sont pas déterministes, donc impossible à reproduire. S'il y avait une seed réutilisable on pourrait détecter facilement les erreurs.
Une manière de détecter des tests interdépendants est l'option
--shuffle
, avec une seed qui permet d'avoir des résultats reproductibles.