You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Le test test_api_mail_domains__list_authenticate échoue de façon sporadique, de façon similaire au test mentionné en détail dans #326 (et pour des raisons que je pense similaires).
Suggestion: l'ajout de pytest-repeat aux dépendances dév permettrait de faire des choses comme
bin/pytest --count=250 <test>
C'est bien pratique pour investiguer des échecs intermittents…
A l'issue de 250 runs, j'obtiens deux échecs. Le message d'erreur est le suivant:
django.core.exceptions.ValidationError: {'__all__': ['User/mail domain relation with this User and Domain already exists.']}
Voici mon hypothèse sur le mécanisme de l'erreur:
Le test s'appuie sur la classe MailDomainFactory pour générer des domaines qu'il associe à des users. Cette génération passe par la méthode create_batch de FactoryBoy, qui délègue ensuite la génération de données de la classe domain_name à Faker. Je suppose que Faker dispose d'un jeu de noms de domaine représentatif et que ce jeu est fini.
Cette méthode ne garantit pas la génération de valeurs distinctes: le problème a déjà été signalé.
Le nombre de noms de domaine possible est probablement conséquent mais il peut cependant arriver que le même nom de domaine soit « tiré » deux fois, ce qui déboucherait sur l'erreur ci-dessus (violation d'une contrainte d'unicité).
Piste de correction: utiliser une liste pré-calculée de 5 noms de domaines distincts.
Plus généralement, il me semble que l'utilisation de valeurs générées aléatoirement dans les TU peut conduire à des échecs de tests rares et inattendus. C'est une technique qui peut être intéressante pour la robustesse des tests (cf. property-based testing) mais qui demande aussi de la prudence.
The text was updated successfully, but these errors were encountered:
Le test
test_api_mail_domains__list_authenticate
échoue de façon sporadique, de façon similaire au test mentionné en détail dans #326 (et pour des raisons que je pense similaires).Suggestion: l'ajout de
pytest-repeat
aux dépendances dév permettrait de faire des choses commebin/pytest --count=250 <test>
C'est bien pratique pour investiguer des échecs intermittents…
A l'issue de 250 runs, j'obtiens deux échecs. Le message d'erreur est le suivant:
django.core.exceptions.ValidationError: {'__all__': ['User/mail domain relation with this User and Domain already exists.']}
Voici mon hypothèse sur le mécanisme de l'erreur:
Le test s'appuie sur la classe MailDomainFactory pour générer des domaines qu'il associe à des users. Cette génération passe par la méthode
create_batch
de FactoryBoy, qui délègue ensuite la génération de données de la classedomain_name
à Faker. Je suppose que Faker dispose d'un jeu de noms de domaine représentatif et que ce jeu est fini.Cette méthode ne garantit pas la génération de valeurs distinctes: le problème a déjà été signalé.
Le nombre de noms de domaine possible est probablement conséquent mais il peut cependant arriver que le même nom de domaine soit « tiré » deux fois, ce qui déboucherait sur l'erreur ci-dessus (violation d'une contrainte d'unicité).
Piste de correction: utiliser une liste pré-calculée de 5 noms de domaines distincts.
Plus généralement, il me semble que l'utilisation de valeurs générées aléatoirement dans les TU peut conduire à des échecs de tests rares et inattendus. C'est une technique qui peut être intéressante pour la robustesse des tests (cf. property-based testing) mais qui demande aussi de la prudence.
The text was updated successfully, but these errors were encountered: