Posté par barmic 🦦 le 01 août 2024 à 15:33. En réponse au journal site de la flamme olympique aux tuileries. Évalué à  7 (+5/-0).
En fait c'est typiquement le cas où tu ne fais pas de site. Tu achète les service d'une boite qui sait faire ça. Parce que tu ne sait pas quelle sera ta charge, tu n'a aucun moyen de savoir si tu va prendre 3 fois le nombre de billets que tu as ou si tu va prendre un DDOS parce que les JO, parce que ça amuse un script kiddy, parce qu'un pays veut faire chier le monde,… Ça existe, tu as des gens qui savent vendre des billets de concert pour Taylor Swift ou Beyoncé, ils n'auront aucun mal à gérer ton flux supplémentaire. Potentiellement tu peux même leur acheter une prestation très courte (genre laisser le site en ligne quelques heures/jours seulement).
Bien coder c'est aussi savoir quand ne pas coder et utiliser une bibliothèque ou un service.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Posté par barmic 🦦 le 01 août 2024 à 12:45. En réponse au journal site de la flamme olympique aux tuileries. Évalué à  9 (+9/-2).
Je te l'ai dis je l'ai expérimenté sur une conférence de 600 personnes hors de Paris.
J'ai passé ces 6 dernières années à voir ce que ça donne les comportements des spectateurs du football lors du coup d'envoi d'un match du PSG (j'aime pas le foot c'est pas une appréciation de l'équipe elle est simplement bien plus suivie que n'importe quelle autre en France).
Sur un site bien codé.
Vraiment je te laisse essayer d'avoir un jour affaire à ce genre de choses avec "un site bien codé". J'ai personnellement vu haproxy (ou plutôt le couple haproxy openssl) à genoux pour beaucoup moins que ça (avant même que du code autre soit impliqué sur du barre métal bien de chez nous avec une connexion d'opérateur bien dimensionnée).
La charge c'est un truc qu'on prend de haut quand on s'est pas encore pété les dents dessus. Ce n'est pas un reproche ça a était mon cas et on apprend que l'on ne gère jamais la charge, mais qu'on a prévu pour gérer une charge donnée.
Ton commentaire n'est qu'une série d'a priori. Je te souhaite un jour de mettre au défit ces a priori avec une prod un peu chargée, c'est très enrichissant.
Posté par barmic 🦦 le 01 août 2024 à 10:43. En réponse au journal site de la flamme olympique aux tuileries. Évalué à  2 (+0/-0).
Ton mail a un format facilement parssable pour trouver la date en question ou il est Ă©crit en langage naturel et doit ĂŞtre lu par un humain ou une IAÂ ?
Posté par barmic 🦦 le 01 août 2024 à 09:58. En réponse au journal site de la flamme olympique aux tuileries. Évalué à  3 (+1/-0).
Ça n'existe pas des frameworks open source de résa où toute la partie complexe (file d'attente, gestion propre des erreurs, …) est déjà faite ?
Ça n'est pas si simple. Pour tenir ce genre d'échelle, ce n'est pas qu'une question de code. Ton déploiement doit aussi être correct et il faut que ton code et ton déploiement bénéficie l'un de l'autre.
Par exemple à mon avis, si je voulais faire ça j’essaierais de partir sur un fonctionnement très asynchrone avec un brocker (pas en mémoire) de messages qui représentera ta requête et on t'enverrais par mail la confirmation de ta réservation. Donc potentiellement je te demanderais d'indiquer 3 ou 4 horaires qui te conviendrais et le bousin sélectionne ce qui est encore possible. En plus on doit pouvoir tenter de faire une stat sur le temps de traitement en fonction de la taille de la file dans le message et te dire qu'on va te confirmer d'ici quelques minutes.
Pour info je connais une asso (techniquement j'ai oublié le nom) qui a tenté de ce lancer dans ce genre de service proposé un site de vente de place pour d'autres association et ça a bien foiré dès que c'est monté un peu en charge (de ce qu'on m'a dit il était impossible de corréler les factures, les paiements et les places réservées, il y avait genre x factures, y paiement et z places réservées et aucun des trois ne correspondait et bien sûr il y a eu de la sur réservation - sans qu'il s'agisse d'une attaque ni que ce soit pour un concert d'Elvis Presley).
Après ça n'enlève pas que de ce que tu décris le site a quand même l'air de bien mal marcher
Posté par barmic 🦦 le 01 août 2024 à 08:52. En réponse au lien HTMX 2.0 est sorti.. Évalué à  3 (+1/-0).
Ton script est buggé il me semble
https://linuxfr.org/users/wilk/liens/htmx-2-0
Posté par barmic 🦦 le 30 juillet 2024 à 12:06. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
C'est le sophisme de la solution parfaite. Ils ont eu un bug donc ils ne font pas de qualité.
il est vrai qu'il fut un temps lointain ou à priori le matériel Apple avait un véritable avantage technologique pour les graphistes.
Dis-moi que tu n'a jamais utilisé une architecture M1 sans me dire que tu n'en a jamais utilisé. Je n'aime pas Apple pour pleins de raisons, mais ça ne doit pas aveugler au point de ne pas voir ce qu'ils font de bien et je suis actuellement obligé d'utiliser un M1, quand il fait plus de 35 chez moi je t'avoue que ça m'arrange par rapport à ma tour que j'aime de tout mon cœur mais qui souffle un air chaud difficilement supportable.
Posté par barmic 🦦 le 29 juillet 2024 à 09:13. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
J'y ai travaillé. ST a surtout besoin que les puces soient livrées sans bug, car on peut pas facilement livrer un fix sur du silicium. L'effort en tests est assez important a ce niveau dans cette industrie en général et a ST en particulier. A l'époque on avait un objectif de nombre de bugs par mm2 de surface, bon c'est toujours un peu couillon ces métriques mais ça démontre l'importance du sujet.
Moi aussi, mais le nombre d'erreur par mm2 est un élément multifactoriel et c'est plus lié aux logiciels des ateliers eux-même qui a ce que je sache ne sont pas fait en internet. Je pensais plus à la gestion des lots parce que c'est un sujet bien plus simple.
Si on livre le logiciel qu'une seule fois
Je comprends ce que tu veux dire, mais la métrique ne me parait pas bonne. L'idée c'est de ne pas tester qu'à la livraison. Si tu as 6 mois de développement tu veut t'assurer que ce qui a était fais le premier jour fonctionne encore 3 mois après et éviter de t'en rendre compte le jour de l'unique livraison.
Mais ce que je n'ai sans doute pas assez fais ressortir c'est que c'est issu d'un alignement des objectifs. Que le manager veuille de la rentabilité à tout prix ou de la qualité ou autre chose n'est pas un problème en soit c'est juste qu'il faut que les développeurs en soient conscients et s'assurer que c'est bien ce que l'on veut (qu'on est ok d'avoir potentiellement beaucoup de retours utilisateurs par exemple).
Posté par barmic 🦦 le 26 juillet 2024 à 21:34. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Ce que tu ne peux pas faire c’est dire “on a des UAT, et ils sont implémentés par l’ingénieur, donc on a pas besoin de faire une passe en profondeur manuelle”.
C'est ce que je disais plus haut, je ne vois pas en quoi dire que les tests d'acceptances peuvent être écris par quelqu'un d'autre que celui qui code la fonctionnalité reviendrait à dire qu'il n'y a pas besoin de test manuel.
On revérifie pas chaque feature a 100%, mais on s’assure de toucher chaque feature, et on passe un peu plus de temps sur les flows les plus importants.
Vous avez une manière de l'évaluer ? C'est quoi une feature ? À quelle point ce processus de test dépend de l’expérience du testeur et de sa forme le jour où il fait ces tests ?
La base données, elle est dans le backend, on parle de tests front end la. Le backend, il a ses propres tests, qui, eux, sont beauuuucoup plus simples à écrire en général.
Tu fais transiter de la données que tu accède à ta donnée via du SQL, du REST, un protocole spécifique, une API de fichier (POSIX ou pas), ça revient au même. Il n'y a pas de différence fondamentale entre chacune de ses options. Il n'y a pas de différence profonde entre un backend qui utilise S3 et un frontend qui fait du CRUD via un REST maison.
[…] réservée à quelqu’un qui bouffe du code toute la journée (pas un qa).
Un QA qui fait de l'automation "bouffe" au moins autant de code qu'un ingé
Posté par barmic 🦦 le 26 juillet 2024 à 18:18. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Ok je viens de comprendre notre malentendu !
Je comprends ton point sur le fait qu'il est probablement impossible de valider une fonctionnalité (surtout UI) par des tests automatisés, mais le fait d'avoir une série de cas automatisé n'empêche pas de faire des tests manuels (c'est là que je ne t'ai pas compris puisque tu avais l'air de les placer en opposition).
La soluce, c’est de gruger. Ton core location delegate trampoline vers ta méthode à toi, qui prend un objet que tu peux instantier. Et tu gruges dans ton test, en appelant cette fonction la directement. Il va effectivement te manquer un bout dans ton test, mais au moins tu peux garantir que tout ce qui vient après le point d’entrée fonctionne comme il faut.
Ce n'est pas de la gruge, c'est segmenter ce que tu test et dans le cas présent c'est probablement ce qui distingue un test d'intégration d'un test unitaire. Ça demande souvent de faire de l'injection de dépendance (le pattern pas forcément les framework qui font tout pour toi) et c'est utile pour segmenter tes tests de manière générale. C'est assez mathématiques plus tu test des bouts simple plus la combination va être limitée et comme ça évolue de manière quadratique (il me semble) faire grandir le scope est très douloureux.
C'est pour ça que la pyramide des tests existe et je suis assez dubitatif de ce que vous faites. Beaucoup de ce qui est interface pure reste de l'algorithmique, tu réorganise les données que tu reçois, tu valide les données pour considérer qu'un formulaire est valide ou non, etc. Mais si vous en êtes content, qui suis-je pour juger ?
Posté par barmic 🦦 le 26 juillet 2024 à 18:02. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  3 (+1/-0).
Mouaif. Je suis loin d’être convaincu. Peut être qu’on bosse comme des porcs chez moi, mais au mieux du mieux, tu va avoir peut être 80% de couverture sur des uat dans le ticket, et uniquement sur la logique métier pure. Toute la partie technique (typiquement, si ton backend se ramasse, backward compat pour appli, race conditions, etc) ne sera pas couverte par ces tests. C’est certainement une bonne base pour commencer ton test plan, mais ça gratte juste la surface.
Les tests d'acceptance ne sont pas fait pour remplacer les TU, comme les tests d'intégration ne sont pas fait pour remplacer les autres. Il tenter de s'approcher de la pyramide des tests est appréciable.
apres, je suis pas sur de suivre. Tu dit que c’est pas raisonnable de tester manuellement chaque nouvelle feature que l’équipe pond?
Non je dis que la pratique qui consiste à avoir un cahier de recette à rejouer à chaque release ça ne marche globalement pas. Il est pas à jour, il est exécuté à l'arrache, on presse les gens pour le faire au plus vite, ils ne sont pas fait assez régulièrement donc on se retrouve avec des situations du genre "c'est normal que ça ne corresponde pas",…
Pour clarifier, ma position c’est que l’automation n’est pas fiable pour valider une nouvelle feature, aussi petite soit elle.
Donc tu n'écris aucun test programmatique parce qu'ils peuvent être déjoué ?
C'est une évidence et je pense même que c'est mathématiquement prouvé, mais ce n'est pas le sujet à mon avis. Il n'existe pas de silver bullet, même la preuve ne fait que supprimer des pans de types d'erreur, mais il demande à n'avoir aucune erreur dans la spécification (sinon tu as juste prouvé que ton logiciel fait bien l'erreur qui est spécifiée).
La question ce n'est pas de savoir si les tests automatisés c'est bien ou s'il faut tester manuellement mais d'avoir le bon test au bon endroit. Et de mon expérience c'est un équilibre à trouver de ce qui est utile à l'équipe (au sens large).
Une stratégie de test ne peux pas s'évaluer hors de contexte. Le faire de faire des benchmark peut être crucial dans des contextes et une perte de temps ailleurs.
Mon point c'est de dire qu'avoir "une certaine" couverture avec des tests (je disais d'acceptance, mais effectivement métier est bien mieux) écris en gherkin permet d'avoir un échange plus fluide entre le product owner/business analyst/utilisateur impliqué et l’ingénieure.
Si tu peux trouver un ingénieur pour écrire le code, tu peux trouver un qa pour le tester. 1 qa pour 3 à 5 développeurs, c’est grosso modo le ratio que tu veux. Ça passe très bien à l’échelle de ce que j’en voit.
Quand tu met à jour une bibliothèque/framework, la base de données ou la version du langage, comment tu fais pour qualifier la prochaine version ?
Posté par barmic 🦦 le 26 juillet 2024 à 15:44. En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à  2 (+0/-0).
Je pense surtout que je n'est pas était clair. J’amende mon commentaire
1. les contributeurs aient une idée fiable de la règle qui va s'appliquer à leur travail - 2. le travail des contributeurs ne soit détruit que dans les pires extrémités (tous les autres moyens d'établir à un consensus ont étaient consommés ou il y a des manquements graves genre respect des gens, appel à la haine, etc) + 2. le travail des contributeurs ne soit détruit que dans les pires extrémités (il y a des manquements graves genre respect des gens, appel à la haine, etc) ou à la suite d'un process menant à un consensus
Posté par barmic 🦦 le 26 juillet 2024 à 14:46. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  5 (+3/-0).
Est-ce que le temps passé à concevoir écrire, tester, corriger des tests se justifie par une meilleure productivité globale ou une meilleure qualité globale ?
Sans la moindre hésitation.
La question c'est quelle est la qualité de ce que tu livre ? Et du coup comment tu t'assure d'être à ce niveau de qualité ?
Tu t'appuie sur des clicher de manager, mais un manager ça ne regarde pas que la rentabilité. Il (ou elle) regarde ses objectifs. Si la boite a pour objectif de vendre des binaires pour le prix le plus faible possible alors oui les retours ça ne l'intéresse pas, mais t'augmenter aussi ne l'intéresse pas ni la satisfaction du client ou de l'utilisateur.
Mais tout le monde ne travail pas dans ces ESN qui tentent de vendre du logiciel au rabais (toutes les ESN ne sont pas comme ça, mais la réputation n'est pas démérité). Après ces entreprises existent (et prospèrent) parce que des clients ne veulent pas mettre d'argent dans leur logiciel, mais ce n'est pas le cas de tous. ST a une nécessité vital que les logiciels critiques de ses salles blanches fonctionnent parfaitement par exemple.
Posté par barmic 🦦 le 26 juillet 2024 à 14:34. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  3 (+1/-0).
Ton kilométrage va varier, en fonction de beaucoup de chose, mais en gros, mon opinion c’est absolument pas, pas pour tester une UX utilisateur comme OP le fait dans son naljour.
Comme je le disais dans le commentaire. Je pensais plus aux tests d'acceptance qui sont écrit dans les users stories. Mais j'aime bien la dichotomie de El Titi et de n'utiliser des tests en gherkin que lorsque c'est métier.
bref, les tests automatisés, c’est fait par des développeurs pour des développeurs, et ca sert à 100% à détecter les régressions, certainement pas à valider la feature en premier lieu. La qa c’est manuel, fait par des des profils précis, et c’est 100% pour ta validation initiale.
Manuellement ça ne monte pas à l'échelle et c'est sujet à nombre d'erreur.
Posté par barmic 🦦 le 26 juillet 2024 à 14:34. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  3 (+2/-1).
En fait on ne parle pas de la même chose quand on parle de complexité, mais c'est ma faute il faudrait aussi parler de criticité.
Si tu va dans une salle blanche de fondeur de puce, le processus par le quel passe un lot peut être très complexe. Il y a un paquet de règles métier qui font qu'on ajoute ou non des étapes, qu'on rejout des étapes avec des paramètres différents qu'on scinde des lots, des fois pour les refusionner, des fois non et ils vivent leur propre vie,… le tout avec une traçabilité complète. Tu prend une puce vendu chez les client, tu peu savoir de quel lot elle faisait parti et quel a été sa vie en salle de production. Et chaque demi heure d'indisponibilité du système c'est la production qui est arrêté, des gens qui ne peuvent pas travailler.
Tu peux ricanner devant la question de tester cela correctement, mais c'est un vrai sujet à partir du moment où on est attaché à la qualité de ce qu'on délivre.
Posté par barmic 🦦 le 26 juillet 2024 à 10:53. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  6 (+4/-0).
Et sans plaisanter, quels sont les gains en matière de qualité et de productivité par rapport à un contrôle humain du visuel et des fonctionnalités ?
La reproductibilité et la vérification bien plus rapide sans nécessité quelqu'un qui s'y colle. C'est pas rien parce que ça peut vouloir dire que tu va faire les vérifications à chaque merge ou chaque jour et donc être beaucoup plus réactif qu'avec une recette qui est faite seulement avant la création d'une nouvelle version.
Ça n'interdit d'ailleurs pas de faire des vérifications manuelles. C'est même généralement fait jusqu'à ce que tu trouve que la vérification manuelle n'a plus d'intérêt (que tes tests soient suffisamment matures).
Il faudra aussi un troisième jeu de tests pour tester les tests.
La seule méthode que je connais c'est le mutation testing, c'est des outils qui modifient ton code aléatoirement et vérifient qu'il y a bien un test qui plante. J'en entends de plus en plus parler j'ai l'impression que c'est une méthodologie qui est entrain de gagner en maturité.
Posté par barmic 🦦 le 26 juillet 2024 à 10:27. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Je dis simplement que ça n'aide pas un junior à faire la distinction et à ne pas se lancer dans l'usage d'outils pas adaptés. Je sais pas comment l'expliquer autrement.
Posté par barmic 🦦 le 26 juillet 2024 à 09:18. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  1 (+1/-2).
Tu présente une application qui est techniquement complexe et fonctionnellement triviale. Ça n'est pas le sujet de ce genre de démarche.
C'est plutôt utile quand le fonctionnel est très complexe/subtile. Tu veux que quelqu'un du domaine puisse lire le test en étant bien sûr que c'est bien ce qu'il pratique au quotidien.
Ça demande de réduire justement le gap entre ce qu'il fait au quotidien et ce qu'il lit. Donc il est nécessaire d'utiliser le même vocabulaire que lui (ça peut passer par utiliser du français voir ne pas utiliser les mots dans le sens qu'ils ont dans le dictionnaire) et écrire les tests dans une forme qui retire autant que possible l'aspect technique est utile.
Posté par barmic 🦦 le 26 juillet 2024 à 07:22. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Je ne suis pas certain de bien comprendre ta remarque je vais donc repréciser ce que je voulais expliquer:
Ça ne change techniquement rien et tu donne le même niveau d'information. On est d'accord là dessus. Mais ça entretien une forme de confusion comme quoi ces tests pourraient ou devraient être écrit en gherkin et tu n'est pas à l'abri que quelqu'un d'un peu motivé se lance là dedans. Utiliser un vocabulaire dédié me semble contribuer à faire la distinction.
Sinon, oui Spock est un bon framework dans le même style mais le Groovy n'a plus guère le vent en poupe aujourd'hui.
Ça c'est une question de hype. Depuis qu'il est passé sous le giron de la fondation Apache, le développement est sécurisé et il a plus de popularité (les mesures du nombre de téléchargements etc). Groovy a l'avantage indéniable de pouvoir utiliser MOP pour faire des choses pas très catholiques.
Kotlin est utilisé hors d'android ? Utilisable oui bien sûr mais c'est probablement un angle mort chez moi je vois très peu de choses passer autour de son écosystème
Posté par barmic 🦦 le 26 juillet 2024 à 00:04. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Le triple AAA et le GWT sont en fait exactement la même chose à un niveau différents pour rendre les tests indépendants et précis.
On est d'accord, mais la proximité de GWT avec Gherkin donne plus l'impression qu'il s'agit d'un gherkin du pauvre. Dis autrement ça tend à donner l'impression qu'on ferait du gherkin si on pouvait alors que c'est pas forcément le lieu.
Parmi les autres principes du BDD on retrouve aussi la notion d'ubiquitous language inspirée du Domain Driven Development et des principes du Clean Coding qui veut qu'on retrouve le langage du domaine jusqu'au niveau du code
Et les aggregats vs les entités oui je connais, même si je trouve que les cas d'usage ou la clean architecture a vraiment du sens est plus limité que ce qui est souvent présenter. Le principe d'avoir des adapters pour tout ne rend pas les choses plus simples, elle déplace un problème vers de l'architecture et les erreur d'architecture sont plus chères que celles de codes "simples". C'est vraiment adapté quand tu as un multi usage de ton métier, quand il est très critique ou quand le logiciel est très gros avec beaucoup de gens sur la même base de code, mais sinon faut vraiment se poser la question avant de se lancer. L'ubiquitus langage et les modélisations à la méthode DDD peuvent apporter plus de bénéfices avec moins de défauts.
Dans le monde Java, pour les TU tu peux adopter aussi ce style avec Kotest par exemple : https://kotest.io/docs/framework/testing-styles.html#behavior-spec Ca me manque avec JUnit.
Ca me fait beaucoup penser Ă Spock.
J'ai pas lu tous les liens mais je n'y manquerait pas.
Posté par barmic 🦦 le 25 juillet 2024 à 21:47. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  3 (+1/-0).
Vraiment super intéressant, je n'étais pas allé jusque là dans ma réflexion personnelle sur la distinction test d'interface par rapport aux tests métiers (je me demande si "behavior" n'a pas aider à la confusion d'ailleurs).
J'aurais peut être un petit bémol ou une remarque au sujet du dévoiement de gherkin. Je trouve que l'utiliser même dans une forme minimale dans des tests unitaires peut aider à structurer. J'y ai même trouvé un avantage certains pour des tests asynchrones où mon bloc then est écrite avant le when (on pose des handler avant de faire l'action). Mais j'avoue qu'après ton explication j'aurais plutôt tendance à utiliser AAA pour éviter les confusions.
Posté par barmic 🦦 le 25 juillet 2024 à 17:22. En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à  2 (+0/-0).
celle-ci d'Einstein également intéressante pour les organisations et que je cite de mémoire : quand quelque-chose ne marche pas, faire plus de la même chose et espérer un résultat différent est le signe de la folie.
Tu as la version latine :
error humanum est perseverare diabolicum
Posté par barmic 🦦 le 25 juillet 2024 à 16:18. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  5 (+4/-1).
Ils posent différents problèmes:
Il est possible d'utiliser selenium de manière programmatique comme une implémentation de gherkin et là ça devient la même approche que playwright ou cypress.
Je considère personnellement de loin, gherkin comme étant une approche beaucoup plus enviable pour les développeurs :
Posté par barmic 🦦 le 25 juillet 2024 à 14:45. En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  8 (+6/-0).
Il est écrit en Typescript : Il n’est donc pas facile à comprendre pour les personnes qui ne développent pas (on entend ici toute personne qui ne comprend pas du code de programmation), et c’est un peu dommage, car il est censé représenter un cas d’utilisation réel. Et on s'en fout en fait, le test est pour vérifier que le développeur ne casse rien lors d'une PR, le test est certes sur une UI mais pour le programmeur par le programmeur pour ne rien casser pendant un développement.
Il est écrit en Typescript : Il n’est donc pas facile à comprendre pour les personnes qui ne développent pas (on entend ici toute personne qui ne comprend pas du code de programmation), et c’est un peu dommage, car il est censé représenter un cas d’utilisation réel.
Et on s'en fout en fait, le test est pour vérifier que le développeur ne casse rien lors d'une PR, le test est certes sur une UI mais pour le programmeur par le programmeur pour ne rien casser pendant un développement.
C'est plus subtile que ça. Tu parle de tests unitaires qui sont des outils de développeurs pour développeur. Gherkin (cette syntaxe à base de given/when/then) est plutôt faite pour écrire des tests d'acceptantes. Donc c'est pas le développeur qui les écris ou en tout cas pas celui qui écris le code et il ne sont pas à destination des développeurs.
Bref, Typescript permet beaucoup de tests, et à ma connaissance ce n'est pas la première fois qu'on essaye des "User centric Usecases Validator" et qu'à chaque fois au bout d'un moment on revient à des trucs plus "programmeur" car une PR a cassé un truc qu'on n'avait pensé tester avec UUV blabla mais qu'en fait le test était pas assez poussé et que le UUV blabla ne permet pas de faire ce test.
Beaucoup de bibliothèques de tests se rapprochent d'une manière ou d'une autre de construction à la gherkin et des outils comme cypress ou playwright ont rendent relativement accessible ces formalismes et ces méthodologies.
Après je trouve que créer une opposition développeur utilisateur vaine et non pertinentes. Gherkin n'est qu'une syntaxe elle permet de rendre plus fin l'écart qu'il y a entre une spécification et le code. L'objectif de ces approches doivent être de créer des ponts pas des oppositions. L'objectif de gherkin c'est de faire collaborer plus étroitement les gens en augmentant la part de formalisme du côté de la spécification et en ayant une forme de test plus lisible par un non technicien.
Posté par barmic 🦦 le 25 juillet 2024 à 12:19. En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à  2 (+0/-0).
Mais si ça se trouve avec un tel mode de fonctionnement avec un appel à une application stricte de règles, tu aurais été pour le verrouillage à la création.
Je n'appelle pas à une application stricte, hein ? Mais pour que :
Le premier point est vraiment important pour l'acceptation des règles par ceux sur qui elles s'appliquent ou que ce soit. L'intransigeance n'est pas la seule manière d'y parvenir et le simple fait d'appliquer le point 2 amha réduit beaucoup des problèmes du premier point.
Des gens avec ce type de mentalité sont en ce moment vent debout contre la création de l'article et s'en désolidarisent.
Il faut faire descendre ce genre de pression. Si on arrêtait les couperai, on gagnerait en qualité des discussions. OSEF des pages qui ont moins de quelques semaines voir mois. La qualité du contenu de Wikipédia s'évalue à terme. Donc au lieu de s'écharper pour savoir s'il faut détruire MAINTENANT, il est possible de dire qu'aucune action sera prise avant un certain seuil (de temps, d'échange, qu'un vote ai emporté une majorité des 2/3,…). Il est aussi possible de ralentir en empêchant de commenter plus d'un certains nombre de fois par heure/jour.
Posté par barmic 🦦 le 25 juillet 2024 à 11:08. En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à  2 (+0/-0).
Il y a un truc qui est ptete un malentendu ici qui est aussi un peu contre intuitif : c'est pas forcément un cadeau d'avoir sa page sur wikipédia pour une personne vivante.
J'en suis parfaitement conscient et c'est pour ça que je parlait des tomates. Mon point n'est pas une question de personne ou un sujet partisan.
C'est wikipédia, en cas de doute on s'en remet à la communauté d'une manière générale. Le principe initial dit "5ème principe fondateur" est là pour maintenir une certaine marge d'interprétation pour pas avoir un cadre administratif trop rigide.
Ce qui pose problème à mon avis, c'est les flous. Ce qui fait qu'une règle est appliquée froidement ou non est arbitraire.
[^] # Re: Solidité
Posté par barmic 🦦 . En réponse au journal site de la flamme olympique aux tuileries. Évalué à  7 (+5/-0).
En fait c'est typiquement le cas où tu ne fais pas de site. Tu achète les service d'une boite qui sait faire ça. Parce que tu ne sait pas quelle sera ta charge, tu n'a aucun moyen de savoir si tu va prendre 3 fois le nombre de billets que tu as ou si tu va prendre un DDOS parce que les JO, parce que ça amuse un script kiddy, parce qu'un pays veut faire chier le monde,… Ça existe, tu as des gens qui savent vendre des billets de concert pour Taylor Swift ou Beyoncé, ils n'auront aucun mal à gérer ton flux supplémentaire. Potentiellement tu peux même leur acheter une prestation très courte (genre laisser le site en ligne quelques heures/jours seulement).
Bien coder c'est aussi savoir quand ne pas coder et utiliser une bibliothèque ou un service.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solidité
Posté par barmic 🦦 . En réponse au journal site de la flamme olympique aux tuileries. Évalué à  9 (+9/-2).
Je te l'ai dis je l'ai expérimenté sur une conférence de 600 personnes hors de Paris.
J'ai passé ces 6 dernières années à voir ce que ça donne les comportements des spectateurs du football lors du coup d'envoi d'un match du PSG (j'aime pas le foot c'est pas une appréciation de l'équipe elle est simplement bien plus suivie que n'importe quelle autre en France).
Vraiment je te laisse essayer d'avoir un jour affaire à ce genre de choses avec "un site bien codé". J'ai personnellement vu haproxy (ou plutôt le couple haproxy openssl) à genoux pour beaucoup moins que ça (avant même que du code autre soit impliqué sur du barre métal bien de chez nous avec une connexion d'opérateur bien dimensionnée).
La charge c'est un truc qu'on prend de haut quand on s'est pas encore pété les dents dessus. Ce n'est pas un reproche ça a était mon cas et on apprend que l'on ne gère jamais la charge, mais qu'on a prévu pour gérer une charge donnée.
Ton commentaire n'est qu'une série d'a priori. Je te souhaite un jour de mettre au défit ces a priori avec une prod un peu chargée, c'est très enrichissant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solidité
Posté par barmic 🦦 . En réponse au journal site de la flamme olympique aux tuileries. Évalué à  2 (+0/-0).
Ton mail a un format facilement parssable pour trouver la date en question ou il est Ă©crit en langage naturel et doit ĂŞtre lu par un humain ou une IAÂ ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Solidité
Posté par barmic 🦦 . En réponse au journal site de la flamme olympique aux tuileries. Évalué à  3 (+1/-0).
Ça n'est pas si simple. Pour tenir ce genre d'échelle, ce n'est pas qu'une question de code. Ton déploiement doit aussi être correct et il faut que ton code et ton déploiement bénéficie l'un de l'autre.
Par exemple à mon avis, si je voulais faire ça j’essaierais de partir sur un fonctionnement très asynchrone avec un brocker (pas en mémoire) de messages qui représentera ta requête et on t'enverrais par mail la confirmation de ta réservation. Donc potentiellement je te demanderais d'indiquer 3 ou 4 horaires qui te conviendrais et le bousin sélectionne ce qui est encore possible. En plus on doit pouvoir tenter de faire une stat sur le temps de traitement en fonction de la taille de la file dans le message et te dire qu'on va te confirmer d'ici quelques minutes.
Pour info je connais une asso (techniquement j'ai oublié le nom) qui a tenté de ce lancer dans ce genre de service proposé un site de vente de place pour d'autres association et ça a bien foiré dès que c'est monté un peu en charge (de ce qu'on m'a dit il était impossible de corréler les factures, les paiements et les places réservées, il y avait genre x factures, y paiement et z places réservées et aucun des trois ne correspondait et bien sûr il y a eu de la sur réservation - sans qu'il s'agisse d'une attaque ni que ce soit pour un concert d'Elvis Presley).
Après ça n'enlève pas que de ce que tu décris le site a quand même l'air de bien mal marcher
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Bug ?
Posté par barmic 🦦 . En réponse au lien HTMX 2.0 est sorti.. Évalué à  3 (+1/-0).
Ton script est buggé il me semble
https://linuxfr.org/users/wilk/liens/htmx-2-0
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
C'est le sophisme de la solution parfaite. Ils ont eu un bug donc ils ne font pas de qualité.
Dis-moi que tu n'a jamais utilisé une architecture M1 sans me dire que tu n'en a jamais utilisé. Je n'aime pas Apple pour pleins de raisons, mais ça ne doit pas aveugler au point de ne pas voir ce qu'ils font de bien et je suis actuellement obligé d'utiliser un M1, quand il fait plus de 35 chez moi je t'avoue que ça m'arrange par rapport à ma tour que j'aime de tout mon cœur mais qui souffle un air chaud difficilement supportable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Moi aussi, mais le nombre d'erreur par mm2 est un élément multifactoriel et c'est plus lié aux logiciels des ateliers eux-même qui a ce que je sache ne sont pas fait en internet. Je pensais plus à la gestion des lots parce que c'est un sujet bien plus simple.
Je comprends ce que tu veux dire, mais la métrique ne me parait pas bonne. L'idée c'est de ne pas tester qu'à la livraison. Si tu as 6 mois de développement tu veut t'assurer que ce qui a était fais le premier jour fonctionne encore 3 mois après et éviter de t'en rendre compte le jour de l'unique livraison.
Mais ce que je n'ai sans doute pas assez fais ressortir c'est que c'est issu d'un alignement des objectifs. Que le manager veuille de la rentabilité à tout prix ou de la qualité ou autre chose n'est pas un problème en soit c'est juste qu'il faut que les développeurs en soient conscients et s'assurer que c'est bien ce que l'on veut (qu'on est ok d'avoir potentiellement beaucoup de retours utilisateurs par exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
C'est ce que je disais plus haut, je ne vois pas en quoi dire que les tests d'acceptances peuvent être écris par quelqu'un d'autre que celui qui code la fonctionnalité reviendrait à dire qu'il n'y a pas besoin de test manuel.
Vous avez une manière de l'évaluer ? C'est quoi une feature ? À quelle point ce processus de test dépend de l’expérience du testeur et de sa forme le jour où il fait ces tests ?
Tu fais transiter de la données que tu accède à ta donnée via du SQL, du REST, un protocole spécifique, une API de fichier (POSIX ou pas), ça revient au même. Il n'y a pas de différence fondamentale entre chacune de ses options. Il n'y a pas de différence profonde entre un backend qui utilise S3 et un frontend qui fait du CRUD via un REST maison.
Un QA qui fait de l'automation "bouffe" au moins autant de code qu'un ingé
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Ok je viens de comprendre notre malentendu !
Je comprends ton point sur le fait qu'il est probablement impossible de valider une fonctionnalité (surtout UI) par des tests automatisés, mais le fait d'avoir une série de cas automatisé n'empêche pas de faire des tests manuels (c'est là que je ne t'ai pas compris puisque tu avais l'air de les placer en opposition).
Ce n'est pas de la gruge, c'est segmenter ce que tu test et dans le cas présent c'est probablement ce qui distingue un test d'intégration d'un test unitaire. Ça demande souvent de faire de l'injection de dépendance (le pattern pas forcément les framework qui font tout pour toi) et c'est utile pour segmenter tes tests de manière générale. C'est assez mathématiques plus tu test des bouts simple plus la combination va être limitée et comme ça évolue de manière quadratique (il me semble) faire grandir le scope est très douloureux.
C'est pour ça que la pyramide des tests existe et je suis assez dubitatif de ce que vous faites. Beaucoup de ce qui est interface pure reste de l'algorithmique, tu réorganise les données que tu reçois, tu valide les données pour considérer qu'un formulaire est valide ou non, etc. Mais si vous en êtes content, qui suis-je pour juger ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  3 (+1/-0).
Les tests d'acceptance ne sont pas fait pour remplacer les TU, comme les tests d'intégration ne sont pas fait pour remplacer les autres. Il tenter de s'approcher de la pyramide des tests est appréciable.
Non je dis que la pratique qui consiste à avoir un cahier de recette à rejouer à chaque release ça ne marche globalement pas. Il est pas à jour, il est exécuté à l'arrache, on presse les gens pour le faire au plus vite, ils ne sont pas fait assez régulièrement donc on se retrouve avec des situations du genre "c'est normal que ça ne corresponde pas",…
Donc tu n'écris aucun test programmatique parce qu'ils peuvent être déjoué ?
C'est une évidence et je pense même que c'est mathématiquement prouvé, mais ce n'est pas le sujet à mon avis. Il n'existe pas de silver bullet, même la preuve ne fait que supprimer des pans de types d'erreur, mais il demande à n'avoir aucune erreur dans la spécification (sinon tu as juste prouvé que ton logiciel fait bien l'erreur qui est spécifiée).
La question ce n'est pas de savoir si les tests automatisés c'est bien ou s'il faut tester manuellement mais d'avoir le bon test au bon endroit. Et de mon expérience c'est un équilibre à trouver de ce qui est utile à l'équipe (au sens large).
Une stratégie de test ne peux pas s'évaluer hors de contexte. Le faire de faire des benchmark peut être crucial dans des contextes et une perte de temps ailleurs.
Mon point c'est de dire qu'avoir "une certaine" couverture avec des tests (je disais d'acceptance, mais effectivement métier est bien mieux) écris en gherkin permet d'avoir un échange plus fluide entre le product owner/business analyst/utilisateur impliqué et l’ingénieure.
Quand tu met à jour une bibliothèque/framework, la base de données ou la version du langage, comment tu fais pour qualifier la prochaine version ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La restauration de Lomita semble indépendante de la DRP, finalement
Posté par barmic 🦦 . En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à  2 (+0/-0).
Je pense surtout que je n'est pas était clair. J’amende mon commentaire
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  5 (+3/-0).
Sans la moindre hésitation.
La question c'est quelle est la qualité de ce que tu livre ? Et du coup comment tu t'assure d'être à ce niveau de qualité ?
Tu t'appuie sur des clicher de manager, mais un manager ça ne regarde pas que la rentabilité. Il (ou elle) regarde ses objectifs. Si la boite a pour objectif de vendre des binaires pour le prix le plus faible possible alors oui les retours ça ne l'intéresse pas, mais t'augmenter aussi ne l'intéresse pas ni la satisfaction du client ou de l'utilisateur.
Mais tout le monde ne travail pas dans ces ESN qui tentent de vendre du logiciel au rabais (toutes les ESN ne sont pas comme ça, mais la réputation n'est pas démérité). Après ces entreprises existent (et prospèrent) parce que des clients ne veulent pas mettre d'argent dans leur logiciel, mais ce n'est pas le cas de tous. ST a une nécessité vital que les logiciels critiques de ses salles blanches fonctionnent parfaitement par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  3 (+1/-0).
Comme je le disais dans le commentaire. Je pensais plus aux tests d'acceptance qui sont Ă©crit dans les users stories.
Mais j'aime bien la dichotomie de El Titi et de n'utiliser des tests en gherkin que lorsque c'est métier.
Manuellement ça ne monte pas à l'échelle et c'est sujet à nombre d'erreur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Formation ?
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  3 (+2/-1).
En fait on ne parle pas de la même chose quand on parle de complexité, mais c'est ma faute il faudrait aussi parler de criticité.
Si tu va dans une salle blanche de fondeur de puce, le processus par le quel passe un lot peut être très complexe. Il y a un paquet de règles métier qui font qu'on ajoute ou non des étapes, qu'on rejout des étapes avec des paramètres différents qu'on scinde des lots, des fois pour les refusionner, des fois non et ils vivent leur propre vie,… le tout avec une traçabilité complète. Tu prend une puce vendu chez les client, tu peu savoir de quel lot elle faisait parti et quel a été sa vie en salle de production. Et chaque demi heure d'indisponibilité du système c'est la production qui est arrêté, des gens qui ne peuvent pas travailler.
Tu peux ricanner devant la question de tester cela correctement, mais c'est un vrai sujet à partir du moment où on est attaché à la qualité de ce qu'on délivre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  6 (+4/-0).
La reproductibilité et la vérification bien plus rapide sans nécessité quelqu'un qui s'y colle. C'est pas rien parce que ça peut vouloir dire que tu va faire les vérifications à chaque merge ou chaque jour et donc être beaucoup plus réactif qu'avec une recette qui est faite seulement avant la création d'une nouvelle version.
Ça n'interdit d'ailleurs pas de faire des vérifications manuelles. C'est même généralement fait jusqu'à ce que tu trouve que la vérification manuelle n'a plus d'intérêt (que tes tests soient suffisamment matures).
La seule méthode que je connais c'est le mutation testing, c'est des outils qui modifient ton code aléatoirement et vérifient qu'il y a bien un test qui plante. J'en entends de plus en plus parler j'ai l'impression que c'est une méthodologie qui est entrain de gagner en maturité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Réflexions sur le journal et le projet mis en lumière
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Je dis simplement que ça n'aide pas un junior à faire la distinction et à ne pas se lancer dans l'usage d'outils pas adaptés. Je sais pas comment l'expliquer autrement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Formation ?
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  1 (+1/-2).
Tu présente une application qui est techniquement complexe et fonctionnellement triviale. Ça n'est pas le sujet de ce genre de démarche.
C'est plutôt utile quand le fonctionnel est très complexe/subtile. Tu veux que quelqu'un du domaine puisse lire le test en étant bien sûr que c'est bien ce qu'il pratique au quotidien.
Ça demande de réduire justement le gap entre ce qu'il fait au quotidien et ce qu'il lit. Donc il est nécessaire d'utiliser le même vocabulaire que lui (ça peut passer par utiliser du français voir ne pas utiliser les mots dans le sens qu'ils ont dans le dictionnaire) et écrire les tests dans une forme qui retire autant que possible l'aspect technique est utile.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Réflexions sur le journal et le projet mis en lumière
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
Ça ne change techniquement rien et tu donne le même niveau d'information. On est d'accord là dessus. Mais ça entretien une forme de confusion comme quoi ces tests pourraient ou devraient être écrit en gherkin et tu n'est pas à l'abri que quelqu'un d'un peu motivé se lance là dedans. Utiliser un vocabulaire dédié me semble contribuer à faire la distinction.
Ça c'est une question de hype. Depuis qu'il est passé sous le giron de la fondation Apache, le développement est sécurisé et il a plus de popularité (les mesures du nombre de téléchargements etc). Groovy a l'avantage indéniable de pouvoir utiliser MOP pour faire des choses pas très catholiques.
Kotlin est utilisé hors d'android ? Utilisable oui bien sûr mais c'est probablement un angle mort chez moi je vois très peu de choses passer autour de son écosystème
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Réflexions sur le journal et le projet mis en lumière
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  2 (+0/-0).
On est d'accord, mais la proximité de GWT avec Gherkin donne plus l'impression qu'il s'agit d'un gherkin du pauvre. Dis autrement ça tend à donner l'impression qu'on ferait du gherkin si on pouvait alors que c'est pas forcément le lieu.
Et les aggregats vs les entités oui je connais, même si je trouve que les cas d'usage ou la clean architecture a vraiment du sens est plus limité que ce qui est souvent présenter. Le principe d'avoir des adapters pour tout ne rend pas les choses plus simples, elle déplace un problème vers de l'architecture et les erreur d'architecture sont plus chères que celles de codes "simples". C'est vraiment adapté quand tu as un multi usage de ton métier, quand il est très critique ou quand le logiciel est très gros avec beaucoup de gens sur la même base de code, mais sinon faut vraiment se poser la question avant de se lancer. L'ubiquitus langage et les modélisations à la méthode DDD peuvent apporter plus de bénéfices avec moins de défauts.
Ca me fait beaucoup penser Ă Spock.
J'ai pas lu tous les liens mais je n'y manquerait pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Réflexions sur le journal et le projet mis en lumière
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  3 (+1/-0).
Vraiment super intéressant, je n'étais pas allé jusque là dans ma réflexion personnelle sur la distinction test d'interface par rapport aux tests métiers (je me demande si "behavior" n'a pas aider à la confusion d'ailleurs).
J'aurais peut être un petit bémol ou une remarque au sujet du dévoiement de gherkin. Je trouve que l'utiliser même dans une forme minimale dans des tests unitaires peut aider à structurer. J'y ai même trouvé un avantage certains pour des tests asynchrones où mon bloc then est écrite avant le when (on pose des handler avant de faire l'action). Mais j'avoue qu'après ton explication j'aurais plutôt tendance à utiliser AAA pour éviter les confusions.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La restauration de Lomita semble indépendante de la DRP, finalement
Posté par barmic 🦦 . En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à  2 (+0/-0).
Tu as la version latine :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  5 (+4/-1).
Ils posent différents problèmes:
Il est possible d'utiliser selenium de manière programmatique comme une implémentation de gherkin et là ça devient la même approche que playwright ou cypress.
Je considère personnellement de loin, gherkin comme étant une approche beaucoup plus enviable pour les développeurs :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à  8 (+6/-0).
C'est plus subtile que ça. Tu parle de tests unitaires qui sont des outils de développeurs pour développeur. Gherkin (cette syntaxe à base de given/when/then) est plutôt faite pour écrire des tests d'acceptantes. Donc c'est pas le développeur qui les écris ou en tout cas pas celui qui écris le code et il ne sont pas à destination des développeurs.
Beaucoup de bibliothèques de tests se rapprochent d'une manière ou d'une autre de construction à la gherkin et des outils comme cypress ou playwright ont rendent relativement accessible ces formalismes et ces méthodologies.
Après je trouve que créer une opposition développeur utilisateur vaine et non pertinentes. Gherkin n'est qu'une syntaxe elle permet de rendre plus fin l'écart qu'il y a entre une spécification et le code. L'objectif de ces approches doivent être de créer des ponts pas des oppositions. L'objectif de gherkin c'est de faire collaborer plus étroitement les gens en augmentant la part de formalisme du côté de la spécification et en ayant une forme de test plus lisible par un non technicien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La restauration de Lomita semble indépendante de la DRP, finalement
Posté par barmic 🦦 . En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à  2 (+0/-0).
Je n'appelle pas à une application stricte, hein ? Mais pour que :
Le premier point est vraiment important pour l'acceptation des règles par ceux sur qui elles s'appliquent ou que ce soit. L'intransigeance n'est pas la seule manière d'y parvenir et le simple fait d'appliquer le point 2 amha réduit beaucoup des problèmes du premier point.
Il faut faire descendre ce genre de pression. Si on arrêtait les couperai, on gagnerait en qualité des discussions. OSEF des pages qui ont moins de quelques semaines voir mois. La qualité du contenu de Wikipédia s'évalue à terme. Donc au lieu de s'écharper pour savoir s'il faut détruire MAINTENANT, il est possible de dire qu'aucune action sera prise avant un certain seuil (de temps, d'échange, qu'un vote ai emporté une majorité des 2/3,…). Il est aussi possible de ralentir en empêchant de commenter plus d'un certains nombre de fois par heure/jour.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La restauration de Lomita semble indépendante de la DRP, finalement
Posté par barmic 🦦 . En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à  2 (+0/-0).
J'en suis parfaitement conscient et c'est pour ça que je parlait des tomates. Mon point n'est pas une question de personne ou un sujet partisan.
Ce qui pose problème à mon avis, c'est les flous. Ce qui fait qu'une règle est appliquée froidement ou non est arbitraire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll