tests: allow tests to run in random order on multiple processes (#89097) #243
No reviewers
Labels
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: entrouvert/chrono#243
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/89097-random-test-order-multiple-processes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
e567b8064b
tod6d8f81b73
WIP: tests: allow tests to run in random order on multiple processesto tests: allow tests to run in random order on multiple processestests: allow tests to run in random order on multiple processesto tests: allow tests to run in random order on multiple processes (#89097)@ -32,2 +32,4 @@
def time_zone(request, settings):
settings.TIME_ZONE = request.param
yield request.param
get_default_timezone.cache_clear()
Je préférerai qu'on utilise la même solution que dans le code de Django:
Bonne idée ! Merci pour la relecture, et encore merci pour le démêlage de des erreurs de ce ticket :)
d6d8f81b73
to5469af9b17
5469af9b17
tocee359e47c
cee359e47c
to3be5981394
@ -29,3 +29,3 @@
@pytest.fixture(params=['Europe/Brussels', 'Asia/Kolkata', 'Brazil/East'])
@pytest.fixture(params=['Europe/Brussels', 'Asia/Kolkata', 'America/Sao_Paulo'])
Mais ça décale ou pousse sous le tapis un problème, ça; non ?
Je n'en suis pas certain, j'avais plutôt l'impression que les tests étaient trop permissifs et réussissaient à charger les infos d'une timezone non supporté par zoneinfo.
La, avec plusieurs processus et sans le
--dist loadfile
les tests partent en erreur aveczoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Brazil/East'
et cette erreur me semblait "légitime" dans le sens ou, effectivement, la zoneBrazil/East
n'existe pas dans/usr/share/zoneinfo
Mais peut être (sûrement) qu'il y a quelque-chose qui m'échappe.
Ok c'est une erreur qui n'était pas notée plus haut. (et je pense que ça signifie qu'en local il te manque tzdata-legacy).
Bien vu !
Du coup d'après toi c'est quoi la solution à privilégier ?
Avec le fin de mot de l'histoire je dirais que le commit peut être laissé en l'état, en mentionnant dans son message que c'est parce que America/Sao_Paulo n'est plus disponible par défaut.
L'absence d'invalidation du cache faisait que le problème était invisible sauf en lançant le test dans plusieurs process ou là chrono.utils.timezone.get_default_timezone() tentait bien de charger Brazil/East mais il y avait bien deux problèmes. C'était invisible pour tous les appels via l'infrastructure de Django (django.utils.timezone.get_default_timezone()) qui utilise pytz qui contient sa propre base de timezone.
Merci à tous les deux :)
@ -25,1 +29,4 @@
}
@receiver(setting_changed)
J'ai testé en lançant les tests avec
tox -e py3-django32-codestyle-coverage -- tests/api/ -n 16
, à priori le receiver est bien pris en compte. Du coup j'imagine que c'est mieux qu'il soit actif pour l'ensemble des tests non ?Oui le plus tôt possible effectivement.
Ok, merci !
3be5981394
to37ad42c2b2
37ad42c2b2
to81b92bcc35
81b92bcc35
to77bda29128
77bda29128
to5a90c4851b