Une procédure de test des sources existait déjà, créée par Christopher Gauthier, permettant de vérifier que les sources étaient encore joignables et qu’on savait lire leurs résultats. Cette procédure était le fruit de nombreux essais et se révélait lente, requérant environ 600s pour tester 300 sources.

Cette nouvelle version conserve la présentation élaborée (et améliorée) avec Christopher, mais j’en ai simplifié le fonctionnement. Des 1000 lignes de JavaScript retirées du fichier principal, j’en ai gardé environ 300, réparties dans plusieurs fichiers.

De plus, avant il fallait changer un réglage interne de Firefox (pour permettre d’ouvrir un onglet par source à tester), alors que maintenant ce n’est qu’une page à visiter et un bouton à cliquer. Toutes les sources sont désormais testées en même temps, dans le même onglet, avec le même terme de recherche (pour l’instant). En effet, il existe un mot magique qu’au moins 75% des sources ont utilisé, et ce n’est pas COVID ! Mais « Europe ». (et oui, j’ai environ 25% des sources à réparer en l’état).

Cette nouvelle version de la procédure est bouclée en 1'30" avec un Firefox récent et en 1er lancé, quand les sources mettent du temps à répondre parce que la recherche n’est pas en cache. (c’est environ 3x plus lent avec un Firefox nightly ASAN).

J’ai testé cette procédure sur différents navigateurs sans noter de différence visible dans les résultats, ni concernant la durée d’exécution. Firefox est même régulièrement le navigateur web supportant les WebExtensions le plus rapide du monde, d’après ce test.

Une anecdote pour finir : il y a des groupes de sources hébergées sur un même serveur. Cela peut être les différentes langues d’un même journal (Euronews), un groupe de journaux locaux rachetés par une même holding (Dauphiné libéré et ses nombreux extends), ou déjà rien que les versions image et vidéo d’un grand journal (ANSA). Et malheureusement ces sources ressortent en erreur quand on lance la procédure de test. J’imagine que le serveur voyant arriver 10 requêtes en même temps (à quelques millisecondes d’intervalle) en provenance d’une même IP, s’empresse de raccrocher les connexions.

Fort heureusement Firefox a récemment introduit une nouvelle API de résolution de domaine pour les WebExtensions (il y a moins d’un an). Ainsi, il est possible de collecter les adresses IP des sources avant de lancer les requêtes et d’ajouter un délais pour celles qui partiront vers le même serveur. Au final ça améliore le fonctionnement le plus central de Meta-Press.es et il aurait été difficile de remarquer le besoin sans coder une cette procédure de test des sources.

Évidemment, les mauvais navigateurs web ne supportent pas encore cette API de gestion de DNS (c’est à dire tous les autres navigateurs web) ce qui oblige à chercher un palliatif sous la forme d’un mélange aléatoire de la liste des sources à interroger et de l’ajout d’un délais fixe entre chaque requêtes.

À vrai dire, vu que la résolution d’un domaine via Firefox prends quelques dizaines de millisecondes, les résultats des deux méthodes sont équivalents…

Mais à nouveau, concernant cet élément fondamental du fonctionnement de Meta-Press.es, Firefox se distingue mondialement.

Force est de constater qu’une exposition prolongée au défragmenteur de Windows durant l’enfance laisse des séquelles durables…

Que ne m’y suis-je mis plus tôt ? Ça aurait évité des régressions, comme celle concernant la sélection automatique des sources sachant chercher un mot ou plusieurs mots, comme il a été rapporté sur Mastodon et corrigé pour cette version.

J’ai utilisé Selenium pour implémenter ces tests, car on ne peut pas cliquer sur une fenêtre modale d' alert avec Karma, et que Puppeteer est en plus limité à un seul navigateur web.

J’ai utilisé un peu de Python pour manipuler Selenium (une bibliothèque de fonction écrite en Java) et eu besoin de pas mal de JavaScript aussi.

Seules les bases de ce grand chantier ont été jetées et un long chemin s’annonce pour arriver à une couverture fonctionnelle intégrale. M’enfin on est déjà à une couverture de 100% de la vérification du chargement des pages, des images, et des liens codés en dur (pas ceux liés aux sources, qui sont testées indépendamment… Vous ai-je parlé de la nouvelle procédure de test des sources !?).

Tester si les images se chargent ou si les liens sont morts pourrait sembler basique. Tout le monde à besoin de ça. Mais non, ce n’est pas évident à mettre en place… Pour commencer la solution s’appuie sur des dépendances (Selenium, Python-Selenium, Geckodriver…) et sur une combinaison de Python et de JavaScript pour piloter l’ensemble.

Et je me suis rapidement senti seul, avec une dernière question en tête (librement traduite) :

- @Siltaer@mamot.fr 30 septembre 2022 12:32, https://mamot.fr/@Siltaer/109087368503328477

Pour obtenir un comportement rationnel de Selunium, il faut attendre que les pages soient complètement chargées, JavaScript compris. Mais ça, c’est encore quelque chose que Selenium ne propose pas. J’ai trouvé deux méthodes pour attendre l’exécution du JavaScript : faire placer par le JavaScript, et en fin de chargement, une classe CSS sur la balise body de la page web par exemple, ou déclarer une variable dans l’objet window et attendre qu’elle soit définie côté Selenium.

Ensuite, Selenium ne sait pas dire si une image a bien été chargée. J’ai donc dû trouver un moyen de faire ça avec du JavaScript, injecté ou appelé depuis Selenium.

Voici deux méthodes pour découvrir si une image a bien été chargée :

Un bon point c’est qu’il n’y a pas besoin de requêtes additionnelles pour obtenir l’info.

Mais on a par contre évidemment besoin de requêtes additionnelles pour déterminer si les liens sont bons (ou cassés).

Comme signalé dans le pouet sur Mastodon, Selenium ne peut pas fournir les codes HTTP de chargement des pages. On peut obtenir cette info en JavaScript, mais seulement pour les liens internes, car on se heurte à la politique CORS dès qu’on vise un autre domaine. Alors pour les liens externes, on repasse côté Python et on lance des requêtes additionnelles indépendantes de Selenium (et on s’arrange pour homogénéiser l’affichage des erreurs).

Je passe sur les découvertes d’authentiques bugs découverts chemins faisant (vu qu’on s’est mis à tester des choses de manière exhaustives…).

Et alors on a une chance d’arriver enfin à faire tourner les tests sans afficher d’erreur dans la console : beaucoup d’émotion face à cette ravissante nouvelle sorte de "rien".

Ça va être un long chemin pour coder les tests de tous les réglages, un par un…