Diagnostic des échecs de test

Discussion avec Copilot peut vous aider à comprendre pourquoi un test échoue et suggère comment le corriger.

Dans cet article

Discussion avec Copilot peut analyser les échecs de test et aider à identifier les causes potentielles.

Exemple de scénario : Tests passant localement mais défaillants dans CI

Imagine un scénario où vous avez un test qui réussit sur votre machine locale, mais échoue parfois en CI. Discussion avec Copilot peut vous aider à identifier la raison de la défaillance.

Dans cet exemple, le code testé définit un service d’ordre simple (order.py), et il existe un test correspondant qui vérifie si une commande a été créée aujourd’hui (test_order_service.py).

Exemple d’invite

L’invite ci-dessous fournit Copilot avec les fichiers de code et de test requis (utilisation #file:) et inclut un copier/coller de l'extrait pertinent tiré de l’échec du CI.

Copilot prompt
Please take a look at this CI failure message. The test passes locally, but intermittently fails in CI. Can you help me figure out if this looks like a code bug, environment issue, or a flaky test?

Failure:

___ TestOrderService.test_order_created_today ___
>       assert order["created_date"] == date.today()
E       AssertionError: assert datetime.date(2024, 1, 15) == datetime.date(2024, 1, 16)

test_order_service.py:45: AssertionError

#file:order.py
#file:test_order_service.py

Exemple de réponse

Remarque

La réponse suivante est un exemple. Les réponses Discussion avec Copilot ne sont pas déterministes, vous pouvez donc obtenir une réponse différente de celle affichée ici.

Discussion avec Copilot remarque que les dates sont exactement séparées d’un jour et identifie qu’il peut s’agir d’un problème de fuseau horaire ou de limite horaire.

L’ordinateur local et l’exécuteur CI peuvent utiliser différents paramètres de fuseau horaire ou dériver today de différentes horloges (heure UTC ou heure locale), de sorte que lorsque le test s’exécute près de minuit, date.today() peut retourner des dates différentes dans chaque environnement.

Discussion avec Copilot suggère de traiter l'échec comme une instabilité de test causée par des hypothèses d'environnement/de temps (et non un bogue logique), et de corriger cela en standardisant la manière dont today est calculé dans différents environnements.

Exemple de scénario 2 : Échecs de test intermittents

Envisagez un scénario où un test réussit parfois et échoue parfois sur la même machine. Discussion avec Copilot peut comparer les journaux des exécutions réussies et échouées pour vous aider à identifier la cause.

Dans cet exemple, le code testé utilise un travail en arrière-plan dans order_service.py pour mettre à jour l'état d'une commande de manière asynchrone, et un test dans test_order_service.py vérifie que l'état final est "processed".

Exemple d’invite

L'invite ci-dessous fournit Copilot avec le message d'échec, les extraits de journal d'une exécution réussie et d'une exécution échouée, ainsi que les fichiers de code pertinents (à l'aide #file:).

Copilot prompt
This test passes sometimes and fails sometimes. Can you compare the logs and help me figure out why?

Failure message:

>       assert order.status == "processed"
E       AssertionError: assert "pending" == "processed"

test_order_service.py:62: AssertionError

Logs from a passing run:
[DEBUG] Created order #1234
[DEBUG] Background job started for order #1234
[DEBUG] Background job completed (52ms)
[DEBUG] Checking order status
[DEBUG] Order #1234 status: processed

Logs from the failing run:
[DEBUG] Created order #1234
[DEBUG] Background job started for order #1234
[DEBUG] Checking order status
[DEBUG] Order #1234 status: pending

#file:order_service.py
#file:test_order_service.py

Exemple de réponse

Remarque

La réponse suivante est un exemple. Les réponses Discussion avec Copilot ne sont pas déterministes, vous pouvez donc obtenir une réponse différente de celle affichée ici.

Discussion avec Copilot compare les deux journaux et remarque que dans l’exécution réussie, le travail en arrière-plan s’est terminé avant la vérification de l’état, tandis que dans l’exécution échouée, l’état a été vérifié pendant que le travail était encore en cours. Discussion avec Copilot remarque qu’il s’agit d’une condition de course, car le test n’attend pas que le travail en arrière-plan se termine.

Discussion avec Copilot suggère d’ajouter un mécanisme pour s’assurer de la fin du travail avant de procéder à l'assertion, comme l’exécution synchrone du travail, l’attente de la fin du travail (par exemple, via un rappel) ou le sondage.

Lectures complémentaires