Je ne comprends pas où tu veux en venir. Aucun souci d'écrire les tests unitaires avec le style Gherkin du moment que tu n'utilises pas un framework type cucumber et que tu le réserves pour des tests de plus haut niveau.
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.
Je ne suis pas certain de bien comprendre ta remarque je vais donc repréciser ce que je voulais expliquer:
Le BDD n'est qu'une extension du TDD (certains diraient que c'est le TDD appliqué de la bonne manière: outside in).
Avec le TDD, le AAA est un pattern pour écrire des test unitaires atomiques et répétables avec les 3 composantes d'un bon test.
Aucune différence entre commenter ton code :
// Arrange
...
// Act
...
// Assert
... et
// Given
...
// When
...
// Then
... ou d'utiliser un framework avec du sucre syntaxique pour ce faire (au delta du reporting près)
Tous ces frameworks sont avant tous destinés aux TUs même si on les appellent frameworks BDD par opposition aux frameworks xUnit. Tout comme le sont les frameworks type Jasmine ou le style describe de Kotest qui aboutissent au même résultat sans se conformer à la syntaxe GWT.
Les frameworks dits "purs BDD" s'attachent à séparer la spécification sous forme textuelle comme base de discussion de l'implémentation comme: Cucumber, Concordion, Fitnesse, …
L'avantage de ces derniers, outre l'aspect collaboration sur les spec est de permettre de réutiliser le lexique par des non techniciens pour composer de nouveaux scénarios. Le gros inconvénient étant leur lourdeur (maintenance du lexique, partage des états entre les steps, …). Même si la démarche BDD est continue au travers des niveaux de tests, elle nécessite des outils différents. D'où leur usage avec circonspection.
Pour ce qui est du DDD, je voulais simplement rappeler le principe de réutilisation du vocabulaire du domaine à tous les niveaux, y compris dans le code. Les considérations de design et d'architecture relèvent d'un autre débat qui sort un peu du périmètre de la discussion.
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.
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. C'est pourquoi il faut limiter le BDD et l'usage du Gherkin à des test de User Stories et non pour des tests de bout en bout qui couvrent des flows utilisateurs plus larges avec différents états (https://martinfowler.com/bliki/UserJourneyTest.html) ou alors il faut abstraire encore plus le métier.
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
Pour revenir au Gherkin, avec Playwright par exemple, même en partant de fichier .feature, je maintiens mes tests lisibles en recourant à la notion de step. Je documente ainsi mes tests sans forcément maintenir le couplage fort entre le fichier .feature et mon code de glue. C'est beaucoup moins contraignant car ca évite de batailler avec les World de Cucumber.js. En plus, je conserve les avantages du runner de PW. C'est un bon compromis lorsque tu n'as pas de contraintes fortes sur la vérification des règles métier.
Déjà, merci d'aborder le sujet du test logiciel sur ce site et de nous présenter une initiative open source: ce n'est pas si fréquent.
De ce que je comprends, UUV est framework de test orienté mot-clé (keyword driven) qui se destine à des non techniciens ou tout au moins des non programmeurs. Il s'agit de mettre à disposition des directives d'automatisation de tests (des mots clés) au travers d'un langage spécialisé (DSL= Domain Specific Language) proche des langages naturels, par opposition aux langages de programmation. Chaque mot-clé ou phrase dispose d'une implémentation par défaut avec la possibilité de rentrer des paramètres.
Il en existe pléthore sur le marché. Un des plus connu est RobotFramework. Voici un exemple minimaliste
UUV quant à lui adopte un formalisme proche du Gherkin qui assimile souvent ces frameworks au BDD (Behavior Driven Development) alors qu'ils n'en relèvent pas (nous y reviendrons). A la différence de Cucumber ou d'autres comme Gauge, qui séparent les spécifications de leur implémentation, mais laissent le soin à l'équipe de dev/test d'implementer tous les mot-clés en conférant toute latitude dans leur implementation, UUV vient avec ses mot-clés assez bas nveau orientés interface utilisateur plutôt que métier et la possibilité d'étendre le lexique.
Pour ce qui est de l'aspect technique, UUV se destine uniquement aux interfaces Web et permet de s'abstraire de Cypress et Playwright, ce qui est un challenge tant leurs architectures sont différentes (le premier embarque son code dans une Webview et tourne dans la même boucle d'exécution que le code applicatif tandis que le second s'appuie sur un protocole distant en mode connecté qui pilote un navigateur: le Chrome Devtools Protocol, à l'instar de Selenium Webdriver qui utilise ResT). Encore une fois Robotframework ou Karaté le permettent tout en étant encore plus génériques et en permettant d'automatiser les applis natives, mobiles, tester les base de données ou des API …
Autre différence avec ces 2 frameworks, tout comme Testerum: ils permettent d'appeler récursivement d'autres mot-clés, permettant de structurer son code de test en couches (métier, UI, …) avant même d'envisager de créer ses propres mots clé avec un langage de programmation et devoir recourir à l'expertise des programmeurs
Plusieurs soucis avec ces frameworks basées sur la syntaxe Gherkin cependant:
Déjà, on ne fait de dévoyer la syntaxe Gherkin qui est intrinsèquement liée à l'approche BDD selon ses concepteurs. Le Behaviour Driven Development est avant tout une méthodologie qui, comme son nom l'indique, entend mener son projet entièrement autour de la notion de comportement, y compris avec les frameworks BDD type Cucumber, et non pas de se transformer en outil de test. Ainsi l'objectif est avant tout de communiquer et collaborer sur les spécifications fonctionnelles en associant tous les acteurs du projet (le métier, le développeur et testeur en tant que rôle) et en raisonnant sur des exemples avec le langage du domaine. Les Example mapping sessions sont un excellent instrument pour ce faire. On peut ainsi illustrer et raisonner sur ces spécifications, les challenger et découvrir ou valider des règles métier avant toute chose, en se concentrant sur le domaine et non sur les interactions homme-machine. De là découle la stratégie du développement qui permet d'implementer le code de l'application et les tests en même avec une un approche descendante (outside in et double boucle TDD : Test d'acceptation -> Test unitaire -> Code ). Ces tests et leur description textuelle sous forme d'exemples deviennent alors de la documentation toujours à jour (living documentation) et des "specifications exécutables" puisqu'on peut les rejouer automatiquement
Il est donc important de se limiter aux règles du métier indépendamment de l'interface utilisateur pour que les examples (tests) restent intelligibles et stables dans le temps. Ceci vient à l'encontre de ces fameux frameworks sachant que l'expressivité et la grammaire de ces langages est très limitée par ailleurs (Given, When Then et des paramètres). On se retrouve donc avec des scenarios illisibles, fragiles et inmaintenables, écrits dans un style impératif, plutôt que déclaratif car couplés à l'interface utilisateur. Le métier ne les consulte plus et les devs/testeurs perdent leur temps à les maintenir avec toutes les contraintes et la perte de temps que ça induit. Bref, on se concentre sur le fait de valider les règles métier et si on suit les bonnes pratiques, on le fait au plus bas niveau possibles où elles s'expriment lorsque c'est possible (l'API ou même le contrôleur, plutôt que le navigateur)
Maintenant à propos des frameworks orientés most clé ou dit low-code:
D'une manière générale, ce qui est vrai pour ces framework basés sur le Gherkin l'est aussi pour tous ces autres frameworks plus génériques dans une moindre mesure. Même si on peut aller assez loin dans l'implémentation de ces tests avec RobotFramework par exemple (structure de contrôle, modularité, variables, …), on ne bénéficie jamais de la même souplesse ni de la robustesse que des frameworks spécifiquement implémentés pour des langages de programmation, car on ne dispose pas de toutes la puissance de ces derniers (paradigmes OOP, structures de contrôles avancées, … répertoires de librairies très larges, intégration poussée avec les EDI, debugging et outres outils , … )
Mon point de vue en guise de conclusion: n'utilisez Cucumber et Gherkin ou un autre framework pur BDD (qui sépare la spec et l'implémentation) uniquement que pour valider et collaborer sur vos règles du domaine avec le metier métier, si nécessaire. Adoptez l'approche BDD sans même ces frameworks lorsque c'est possible et implémentez vos tests avec les mêmes stacks que celle de votre application. Si vous intégrez des testeurs dans vos équipes: un bon automaticien doit savoir coder et enfin restez à distance de ces frameworks low-code dès lors qu'il s'agit d'étendre votre patrimoine de tests.
Par contre je ne suis pas certain non plus que ta dernière remarque s'applique. Les mot clés distinguent bien "title" et "button" qui ne sont donc pas interchangeable.
Là où ca montre déjà quelques limites en revanche c'est qu'il ya a souvent des cas tordus où l'on doit composer avec différentes approches pour accéder à un éléments precis dans le DOM, ce que permette des frameworks avancés comme ici : https://playwright.dev/docs/locators#filtering-locators
D'après la doc d'UUV, je n'ai pas l'impression que ce soit possible et on se retrouve donc avec l'obligation d'introduire des test-ids pour lever les ambiguïtés.
Yep, et ces testIds (euh… Perso c'était pas ajouté pour le fun, l'ID 'start-button' est utilisé ensuite pour raison X ou Y dans le code JS, par exemple le désactiver si un champs n'est pas rempli) ont une autre finalité dans le test, tu n'as pas montré dans
J'ai l'impression que tu confonds les data-test-id qui n'ont vocation qu'à servir pour les tests pour simplifier la localisation des éléments et perdurer dans le temps, après refactoring, et les attributs "id" du DOM.
Playwright, lui, vient directement avec ce type de locator orientés utilisateurs par défaut et privilégie cette approche, reléguant le data-test-id à un second choix. En effet, leur usage nécessite une certaine rigueur et une bonne communication entre développeurs et testeurs s'il s'agit d'équipes différentes. Il faut aussi se poser la question de la pertinence de conserver ces attributs au moment du déploiement.
L'approche orienté utilisateur; elle, est contrainte par l'internationalisation même si celle-ci peut être facilement prise en charge avec les fixtures de Playwright et l'abstraction de l'UI derrière le Page Object Model.
Ah mince, Fireship la mentionnait comme open-source et je n'ai pas reverifié. Ils ont peut-être changé leur modèle en cours de route comme quasiment presque toutes les dbs pas développées par des communautés aujourd'hui.
Et donc ? Oui tout comme certains métiers sont trustés par des femmes dans plein d'autres domaines.
Le fait est que ton exemple ne démontre rien. Sois beau joueur !
Que des changements sont possibles, qu'elles sont légitimes à se lancer si elles s'imaginent en avocates ou alors on parle uniquement d'avocats et ptete qu'elles devront dans ce cas passer la première réticence qui fait qu'"avocats" étant genré de fait au masculin c'est plus difficile d'imaginer une femme ?
On ne saurait mieux dire.
Tu as aussi le produit en opensource avec un client libre et serveur que tu ne peux pas installer toi-même ou qui comporte des modules fermés, …
Le problème vient du fait qu'une mise à jour requiert la création d'un compte pour accéder à tes propres données ou de downgrader ou de forker … du jour au lendemain.
Ils seraient 60% à voter fascistes
…
Ils provoquent les comportements dangereux par des attitudes ou mise en scène passive-agressive afin d'obtenir de l'autre la faute qui justifiera leur violence
Tu as oublié de preciser qu'à présent ils appellent à la sédition si leurs exigences ne sont pas satisfaites par la voix de leurs syndicats
Concernant mes «insinuations» sur lesquelles son fils serait délinquant qui a véritablement blessé des personnes contrairement à Nahel qui n'aura jamais d'occasions de le faire à présent. Extrait du Parisien:
vient d’être mis en examen pour blessures involontaires ayant entraîné une incapacité totale de travail (ITT) inférieure ou égale à trois mois, avec deux circonstances aggravantes : son alcoolémie positive, et la violation manifestement délibérée d’une obligation particulière de prudence ou de sécurité.
Concernant cette fois les insinuations de Zemmour qui laissent le champ libre à l'interprétation que n'a pas manqué de faire sa clique (Bien fait pour sa gueule, c'est un petite racaille récidiviste), le tweet en question:
La mort d'une jeune homme est toujours triste, quel qu'il soit. Mais il n'était pas « un ange » comme le dit Kylian Mbappé. Il avait à 17 ans des antécédents judiciaires déjà très fournis.
En revanche, quand on manifeste dans le calme pour une enfant qui a été découpée en morceaux par une algérienne en situation irrégulière, la petite Lola, on vous traite de « factieux », de « fascistes », de « racistes » et d'infames « récupérateurs ».
Allez, en prime je te livre le tweet polémique (Ô mon dieu) de MBappé à ce propos
J’ai mal à ma France. 💙🤍💔💔💔
Une situation inacceptable.
Tout mes pensées vont pour la famille et les proches de Naël, ce petit ange parti beaucoup trop tôt.
[^] # Re: Réflexions sur le journal et le projet mis en lumière
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
Je ne comprends pas où tu veux en venir. Aucun souci d'écrire les tests unitaires avec le style Gherkin du moment que tu n'utilises pas un framework type cucumber et que tu le réserves pour des tests de plus haut niveau.
[^] # Re: Réflexions sur le journal et le projet mis en lumière
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 3.
Je ne suis pas certain de bien comprendre ta remarque je vais donc repréciser ce que je voulais expliquer:
Le BDD n'est qu'une extension du TDD (certains diraient que c'est le TDD appliqué de la bonne manière: outside in).
Avec le TDD, le AAA est un pattern pour écrire des test unitaires atomiques et répétables avec les 3 composantes d'un bon test.
Aucune différence entre commenter ton code :
et// Arrange
...
// Act
...
// Assert
...
ou d'utiliser un framework avec du sucre syntaxique pour ce faire (au delta du reporting près)// Given
...
// When
...
// Then
...
Tous ces frameworks sont avant tous destinés aux TUs même si on les appellent frameworks BDD par opposition aux frameworks xUnit. Tout comme le sont les frameworks type Jasmine ou le style describe de Kotest qui aboutissent au même résultat sans se conformer à la syntaxe GWT.
Les frameworks dits "purs BDD" s'attachent à séparer la spécification sous forme textuelle comme base de discussion de l'implémentation comme: Cucumber, Concordion, Fitnesse, …
L'avantage de ces derniers, outre l'aspect collaboration sur les spec est de permettre de réutiliser le lexique par des non techniciens pour composer de nouveaux scénarios. Le gros inconvénient étant leur lourdeur (maintenance du lexique, partage des états entre les steps, …). Même si la démarche BDD est continue au travers des niveaux de tests, elle nécessite des outils différents. D'où leur usage avec circonspection.
Pour ce qui est du DDD, je voulais simplement rappeler le principe de réutilisation du vocabulaire du domaine à tous les niveaux, y compris dans le code. Les considérations de design et d'architecture relèvent d'un autre débat qui sort un peu du périmètre de la discussion.
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.
[^] # Re: Réflexions sur le journal et le projet mis en lumière
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 4.
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. C'est pourquoi il faut limiter le BDD et l'usage du Gherkin à des test de User Stories et non pour des tests de bout en bout qui couvrent des flows utilisateurs plus larges avec différents états (https://martinfowler.com/bliki/UserJourneyTest.html) ou alors il faut abstraire encore plus le métier.
Le blog que j'ai déjà pointé illustre bien cette problématique: https://automationpanda.com/2018/02/03/are-gherkin-scenarios-with-multiple-when-then-pairs-okay/
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
Si tu es intéressé par tous les moyens de documenter ton code par le bas et ainsi éviter la désynchronisation entre les 2, couvrant d'autres aspects que le BDD et toutes les techniques à mettre en oeuvre, je te recommande cet ouvrage très intéressant: https://www.google.fr/books/edition/Living_Documentation/8_6ZDwAAQBAJ?hl=en&gbpv=1&printsec=frontcover
Pour revenir au Gherkin, avec Playwright par exemple, même en partant de fichier .feature, je maintiens mes tests lisibles en recourant à la notion de step. Je documente ainsi mes tests sans forcément maintenir le couplage fort entre le fichier .feature et mon code de glue. C'est beaucoup moins contraignant car ca évite de batailler avec les World de Cucumber.js. En plus, je conserve les avantages du runner de PW. C'est un bon compromis lorsque tu n'as pas de contraintes fortes sur la vérification des règles métier.
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.
# Réflexions sur le journal et le projet mis en lumière
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 6.
Déjà, merci d'aborder le sujet du test logiciel sur ce site et de nous présenter une initiative open source: ce n'est pas si fréquent.
De ce que je comprends, UUV est framework de test orienté mot-clé (keyword driven) qui se destine à des non techniciens ou tout au moins des non programmeurs. Il s'agit de mettre à disposition des directives d'automatisation de tests (des mots clés) au travers d'un langage spécialisé (DSL= Domain Specific Language) proche des langages naturels, par opposition aux langages de programmation. Chaque mot-clé ou phrase dispose d'une implémentation par défaut avec la possibilité de rentrer des paramètres.
Il en existe pléthore sur le marché. Un des plus connu est RobotFramework. Voici un exemple minimaliste
UUV quant à lui adopte un formalisme proche du Gherkin qui assimile souvent ces frameworks au BDD (Behavior Driven Development) alors qu'ils n'en relèvent pas (nous y reviendrons). A la différence de Cucumber ou d'autres comme Gauge, qui séparent les spécifications de leur implémentation, mais laissent le soin à l'équipe de dev/test d'implementer tous les mot-clés en conférant toute latitude dans leur implementation, UUV vient avec ses mot-clés assez bas nveau orientés interface utilisateur plutôt que métier et la possibilité d'étendre le lexique.
Beaucoup de frameworks s'inspirent de cette idée avec les mêmes limitations et inconvénients: Karate, Testerum, … et même avec RobotFramework c'est possible
Pour ce qui est de l'aspect technique, UUV se destine uniquement aux interfaces Web et permet de s'abstraire de Cypress et Playwright, ce qui est un challenge tant leurs architectures sont différentes (le premier embarque son code dans une Webview et tourne dans la même boucle d'exécution que le code applicatif tandis que le second s'appuie sur un protocole distant en mode connecté qui pilote un navigateur: le Chrome Devtools Protocol, à l'instar de Selenium Webdriver qui utilise ResT). Encore une fois Robotframework ou Karaté le permettent tout en étant encore plus génériques et en permettant d'automatiser les applis natives, mobiles, tester les base de données ou des API …
Autre différence avec ces 2 frameworks, tout comme Testerum: ils permettent d'appeler récursivement d'autres mot-clés, permettant de structurer son code de test en couches (métier, UI, …) avant même d'envisager de créer ses propres mots clé avec un langage de programmation et devoir recourir à l'expertise des programmeurs
Plusieurs soucis avec ces frameworks basées sur la syntaxe Gherkin cependant:
Déjà, on ne fait de dévoyer la syntaxe Gherkin qui est intrinsèquement liée à l'approche BDD selon ses concepteurs. Le Behaviour Driven Development est avant tout une méthodologie qui, comme son nom l'indique, entend mener son projet entièrement autour de la notion de comportement, y compris avec les frameworks BDD type Cucumber, et non pas de se transformer en outil de test. Ainsi l'objectif est avant tout de communiquer et collaborer sur les spécifications fonctionnelles en associant tous les acteurs du projet (le métier, le développeur et testeur en tant que rôle) et en raisonnant sur des exemples avec le langage du domaine. Les Example mapping sessions sont un excellent instrument pour ce faire. On peut ainsi illustrer et raisonner sur ces spécifications, les challenger et découvrir ou valider des règles métier avant toute chose, en se concentrant sur le domaine et non sur les interactions homme-machine. De là découle la stratégie du développement qui permet d'implementer le code de l'application et les tests en même avec une un approche descendante (outside in et double boucle TDD : Test d'acceptation -> Test unitaire -> Code ). Ces tests et leur description textuelle sous forme d'exemples deviennent alors de la documentation toujours à jour (living documentation) et des "specifications exécutables" puisqu'on peut les rejouer automatiquement
Il est donc important de se limiter aux règles du métier indépendamment de l'interface utilisateur pour que les examples (tests) restent intelligibles et stables dans le temps. Ceci vient à l'encontre de ces fameux frameworks sachant que l'expressivité et la grammaire de ces langages est très limitée par ailleurs (Given, When Then et des paramètres). On se retrouve donc avec des scenarios illisibles, fragiles et inmaintenables, écrits dans un style impératif, plutôt que déclaratif car couplés à l'interface utilisateur. Le métier ne les consulte plus et les devs/testeurs perdent leur temps à les maintenir avec toutes les contraintes et la perte de temps que ça induit. Bref, on se concentre sur le fait de valider les règles métier et si on suit les bonnes pratiques, on le fait au plus bas niveau possibles où elles s'expriment lorsque c'est possible (l'API ou même le contrôleur, plutôt que le navigateur)
Il suffit de relire le blog même de Cucumber pour comprendre comme cet outil a été mal utilisé.
Maintenant à propos des frameworks orientés most clé ou dit low-code:
D'une manière générale, ce qui est vrai pour ces framework basés sur le Gherkin l'est aussi pour tous ces autres frameworks plus génériques dans une moindre mesure. Même si on peut aller assez loin dans l'implémentation de ces tests avec RobotFramework par exemple (structure de contrôle, modularité, variables, …), on ne bénéficie jamais de la même souplesse ni de la robustesse que des frameworks spécifiquement implémentés pour des langages de programmation, car on ne dispose pas de toutes la puissance de ces derniers (paradigmes OOP, structures de contrôles avancées, … répertoires de librairies très larges, intégration poussée avec les EDI, debugging et outres outils , … )
Mon point de vue en guise de conclusion: n'utilisez Cucumber et Gherkin ou un autre framework pur BDD (qui sépare la spec et l'implémentation) uniquement que pour valider et collaborer sur vos règles du domaine avec le metier métier, si nécessaire. Adoptez l'approche BDD sans même ces frameworks lorsque c'est possible et implémentez vos tests avec les mêmes stacks que celle de votre application. Si vous intégrez des testeurs dans vos équipes: un bon automaticien doit savoir coder et enfin restez à distance de ces frameworks low-code dès lors qu'il s'agit d'étendre votre patrimoine de tests.
[^] # Re: Tests différents (ou partiels)
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
Ok, je saisis l'idée
[^] # Re: Tests différents (ou partiels)
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
Par contre je ne suis pas certain non plus que ta dernière remarque s'applique. Les mot clés distinguent bien "title" et "button" qui ne sont donc pas interchangeable.
Là où ca montre déjà quelques limites en revanche c'est qu'il ya a souvent des cas tordus où l'on doit composer avec différentes approches pour accéder à un éléments precis dans le DOM, ce que permette des frameworks avancés comme ici : https://playwright.dev/docs/locators#filtering-locators
D'après la doc d'UUV, je n'ai pas l'impression que ce soit possible et on se retrouve donc avec l'obligation d'introduire des test-ids pour lever les ambiguïtés.
[^] # Re: Tests différents (ou partiels)
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 3.
Je n'ai pas commenté le reste de ton argumentation sur laquelle je suis à peu près en accord, juste reprécisé ce point.
Je pense me fendre d'un commentaire détaillé aussi un peu plus tard pour réagir sur le journal et le projet mis en avant.
[^] # Re: Tests différents (ou partiels)
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 5.
J'ai l'impression que tu confonds les data-test-id qui n'ont vocation qu'à servir pour les tests pour simplifier la localisation des éléments et perdurer dans le temps, après refactoring, et les attributs "id" du DOM.
Là où c'est amusant, c'est que Cypress préconise leur usage systématique et suggère d'utiliser la Testing Library en plus, si on veut privilégier une approche "user centric".
Playwright, lui, vient directement avec ce type de locator orientés utilisateurs par défaut et privilégie cette approche, reléguant le data-test-id à un second choix. En effet, leur usage nécessite une certaine rigueur et une bonne communication entre développeurs et testeurs s'il s'agit d'équipes différentes. Il faut aussi se poser la question de la pertinence de conserver ces attributs au moment du déploiement.
L'approche orienté utilisateur; elle, est contrainte par l'internationalisation même si celle-ci peut être facilement prise en charge avec les fixtures de Playwright et l'abstraction de l'UI derrière le Page Object Model.
# Pendant ce temps-là chez Microsoft
Posté par El Titi . En réponse au journal Redis Open Source bronsonisé. Évalué à 4.
https://korben.info/garnet-cache-revolutionnaire-microsoft-redis-memcached.html
# RestClient ?
Posté par El Titi . En réponse au journal Spring Boot 3.2.0 est dehors. Évalué à 2. Dernière modification le 23 décembre 2023 à 16:46.
Quel est son intérêt par rapport à WebClient ?
[^] # Re: Surreal DB
Posté par El Titi . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4.
Et l'open-source washing habituel.
Dayssu je suis !
[^] # Re: Surreal DB
Posté par El Titi . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 3.
Les ptits coquins : https://github.com/surrealdb/surrealdb/commit/d8c53da443ff5ed49381cf991a06d2c4ca724e71
[^] # Re: Surreal DB
Posté par El Titi . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 3.
Ah mince, Fireship la mentionnait comme open-source et je n'ai pas reverifié. Ils ont peut-être changé leur modèle en cours de route comme quasiment presque toutes les dbs pas développées par des communautés aujourd'hui.
Quel dommage !
[^] # Re: Surreal DB
Posté par El Titi . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 2.
Il a aussi produit un tuto sur cette DB.
# Surreal DB
Posté par El Titi . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 2.
Jette un oeil à SurealDB, une base multi-modèle récente qui supporte Python.
Fireship a fait une petite vidéo sur ce sujet.
# Autre lien intéressant:
Posté par El Titi . En réponse au lien Why the Godfather of A.I. Fears What He’s Built. Évalué à 2.
https://www.youtube.com/watch?v=E14IsFbAbpI
Résumé par ici
[^] # Re: on dirait que ça ne joue pas
Posté par El Titi . En réponse au lien «En français, le masculin fait l’homme, le dominant, il ne “fait pas le neutre”» (article partiel). Évalué à 2.
Et donc ? Oui tout comme certains métiers sont trustés par des femmes dans plein d'autres domaines.
Le fait est que ton exemple ne démontre rien. Sois beau joueur !
[^] # Re: on dirait que ça ne joue pas
Posté par El Titi . En réponse au lien «En français, le masculin fait l’homme, le dominant, il ne “fait pas le neutre”» (article partiel). Évalué à 5.
Très beau contre-exemple qui démontre parfaitement qu'utiliser le terme "avocat" n'entrave pas les vocations féminines.
Merci
[^] # Re: merci et venv
Posté par El Titi . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 3.
Si c'est pour du dev, poetry est la simplicité même.
poetry init, poetry add, poetry install et poetry shell, et tu as tout ce qu'il faut, y compris la détection des venvs dans VS Code.
[^] # Re: il est ou le problème ?
Posté par El Titi . En réponse au journal Guide d'openwashing : comment passer d'un projet opensource à un logiciel bridé et privateur ?. Évalué à 3.
On dirait que certains ont écouté ton conseil avisé :
https://github.com/ArchGPT/insomnium
[^] # Re: il est ou le problème ?
Posté par El Titi . En réponse au journal Guide d'openwashing : comment passer d'un projet opensource à un logiciel bridé et privateur ?. Évalué à 8.
On ne saurait mieux dire.
Tu as aussi le produit en opensource avec un client libre et serveur que tu ne peux pas installer toi-même ou qui comporte des modules fermés, …
[^] # Re: il est ou le problème ?
Posté par El Titi . En réponse au journal Guide d'openwashing : comment passer d'un projet opensource à un logiciel bridé et privateur ?. Évalué à 6.
Le problème vient du fait qu'une mise à jour requiert la création d'un compte pour accéder à tes propres données ou de downgrader ou de forker … du jour au lendemain.
[^] # Re: vous, moi et notre société
Posté par El Titi . En réponse au lien La France doit se pencher sur les profonds problèmes de racisme parmi la police selon l'ONU. Évalué à 9.
Tu as oublié de preciser qu'à présent ils appellent à la sédition si leurs exigences ne sont pas satisfaites par la voix de leurs syndicats
https://pbs.twimg.com/media/Fz41wyyWAAg6CXm?format=jpg&name=large
[^] # Re: Tirs mortels
Posté par El Titi . En réponse au lien Tirs mortels en France: un problème systémique (vidéo, 3min). Évalué à 2.
Alors je vais répondre une toute dernière fois:
Concernant mes «insinuations» sur lesquelles son fils serait délinquant qui a véritablement blessé des personnes contrairement à Nahel qui n'aura jamais d'occasions de le faire à présent. Extrait du Parisien:
Concernant cette fois les insinuations de Zemmour qui laissent le champ libre à l'interprétation que n'a pas manqué de faire sa clique (Bien fait pour sa gueule, c'est un petite racaille récidiviste), le tweet en question:
Allez, en prime je te livre le tweet polémique (Ô mon dieu) de MBappé à ce propos
Sur ce bon WE !
[^] # Re: Tirs mortels
Posté par El Titi . En réponse au lien Tirs mortels en France: un problème systémique (vidéo, 3min). Évalué à 4.
Je laisse tomber. Tu n'as visiblement pas envie de comprendre mes propos.