# Point stabilité, mise à jour des dépendance & qualité de code **URL:** \ **Category:** Développement\ **Created:** [Février 22, 2021, 10:57 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121 "2021-02-22T10:57:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Février 22, 2021, 10:57 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/1 "2021-02-22T10:57:20Z")
Salut à tous ! Les deux gros développements du moment: Multi-utilisateurs & présence bluetooth dans Gladys 4 venant d’être mergée, je pense qu’il est temps de faire une petite pause niveau fonctionnalité et d’investir un peu de temps sur la stabilité, les mise à jour majeures des dépendances et la qualité du code. Je pense qu’il est sain de faire ça régulièrement pour être sur que le projet continue d’être d’aussi bonne qualité qu’au début ! **Dépendances:** - J’en parlais hier, il devient critique de revoir le process de build du frontend, encore bloqué sous preact-cli@2.0.0: [Mise à jour du build du front (preact-cli@2 actuellement)](https://community.gladysassistant.com/t/mise-a-jour-du-build-du-front-preact-cli-2-actuellement/6118) - Au niveau DB, on est sous Sequelize 4 actuellement, alors que Sequelize 6.5.0 est sorti. Je pense qu’il y a beaucoup de petites optimisations/bugfix qui ont du sortir entre ces deux versions, et ça pourrait faire un grand bien au projet de mettre à jour ! - On est toujours en Node 12.xx, alors que Node 14 est la version LTS actuelle la plus récente. - Côté frontend, il va falloir retirer momentjs qui est super lourd, et deprecated ! datejs que l’on utilise dans le frontend fait tout autant le travail, en plus léger. - vis-data et vis-network prend une place folle pour pas grand chose, ça vaut vraiment le coup de le retirer. - unistore, la librarie de state managment qu’on utilise, a été mise à jour et je pense qu’il faudrait vraiment y passer ! D’ailleurs, de manière générale, je pense qu’il faut qu’on arrête de l’utiliser pour les données de composants, et se restreindre au variable globale (httpClient, user, c’est à peut près tout 😛 ). On a pas mal de petit bug qui sont du au fait qu’on utilise ce store global pour stocker des états locaux au composants. C’est moi qui avait mis ça en place, à tord 🙂 Qu’en pensez-vous ? ---
**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\ **Post date:** [Février 22, 2021, 11:21 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/2 "2021-02-22T11:21:27Z")
> [@pierre-gilles](#): > > Côté frontend, il va falloir retirer momentjs qui est super lourd, et deprecated ! datejs que l’on utilise dans le frontend fait tout autant le travail, en plus léger. Il y a une confusion entre frontend et backend, ou momentjs ET datejs sont utilisés en parallèle dans le frontend ? > [@pierre-gilles](#): > > vis-data et vis-network prend une folle pour pas grand chose, ça vaut vraiment le coup de le retirer. Prends une folle ? C’est à dire 😅 Pour le reste, je suis tout à fait d’accord, même si je peux pas encore donner un coup de main dessus… La stabilité c’est super important et une réécriture est souvent nécessaire, tu l’as montré régulièrement en 4 versions de Gladys …! Chapeau 🙂 ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Février 22, 2021, 12:01 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/3 "2021-02-22T12:01:58Z")
> [@lmilcent](#): > > Il y a une confusion entre frontend et backend, ou momentjs ET datejs sont utilisés en parallèle dans le frontend ? momentjs et datejs sont utilisé côté frontend. En fait on a de la chance, momentjs n’est utilisé qu’à un seul endroit: le calendrier 🙂 C’est de ma faute, j’ai laissé ça passé dans la review de la PR, mais clairement il faut se débarrasser de moment. > [@lmilcent](#): > > Prends une folle ? C’est à dire 😅 prendre une \*place folle 🙂 Pardon j’ai loupé un mot ! > [@lmilcent](#): > > Pour le reste, je suis tout à fait d’accord, même si je peux pas encore donner un coup de main dessus… La stabilité c’est super important et une réécriture est souvent nécessaire, tu l’as montré régulièrement en 4 versions de Gladys …! Chapeau 🙂 Top! Effectivement, je pense que dans tout projet informatique il faut avoir l’habitude de dédier au moins 20% du temps à de la réduction de dette technique. ça permet d’avoir un projet à jour, maintenable, et clean 🙂 ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 1, 2021, 8:20 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/4 "2021-03-01T08:20:22Z")
@AlexTrovato @cicoub13 @VonOx Je ne sais pas si vous avez vu mon post, vous en pensez quoi ? ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [Mars 1, 2021, 6:20 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/5 "2021-03-01T18:20:05Z")
> preact-cli@3 Oui, mais je pense que les changements Front majeurs sont difficiles aujourd’hui car 0 tests. Même remarque pour unistore un peu plus bas. Est-ce que l’idée, c’est de réinitialiser un projet vide avec la version 3 et de copier le code Gladys dans ce nouveau projet à jour ? > Sequelize 6.5.0 Si on garde SQLite, go pour cette version. Je peux aider > **[Upgrade to v6 | Sequelize](https://sequelize.org/docs/v6/other-topics/upgrade/)** > > Sequelize v6 is the next major release after v5. Below is a list of breaking changes to help you upgrade. > Node 14 Je vois déjà la MR et ça devrait être assez facile > retirer momentjs pour remplacer par datejs Yes, pareil : pas mal de tests manuels à faire côté Front > vis-data et vis-network Je ne sais pas à quoi ça sert, je pense qu’on peut le virer. > unistore Tu voudrais utiliser quoi à la place pour le store Front ? ---
**Author:** ![AlexTrovato](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/alextrovato/32/10705_2.png) [@AlexTrovato](https://community.gladysassistant.com/u/AlexTrovato)\ **Post date:** [Mars 1, 2021, 6:40 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/6 "2021-03-01T18:40:41Z")
@pierre-gilles je pense en effet que c’est nécessaire, et que c’est même quelque chose qu’il faut faire “au jour le jour” et éviter d’attendre 6 mois pour le faire. Comme le dit @cicoub13 il y a pas de sujets côté front. On devrait peut-être passer du temps sur des tests du front avant migrations / changements histoire de s’assurer d’une certaines campagnes de non régression, même si cela ne remplacera pas les tests faits par un humain. On en avait déjà parlé, et si je me souviens bien, on avait mentionné [https://www.cypress.io/](https://www.cypress.io/) Je pense qu’on va devoir y passer. Le top serait donc qu’on se dispatch les tâches, et rien n’empêche de commencer les migrations sans les tests cypress. Qui prend quoi ? (je prends nodejs v14 😛 ) Perso moyen chaud pour la DB, mais je veux bien me lancer sur cypress, au moins histoire de poser les bases et introduire les tests sur le “core” (il ne faudra pas être pressé, c’est une découverte pour moi) . ---
**Author:** ![VonOx](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/vonox/32/10128_2.png) [@VonOx](https://community.gladysassistant.com/u/VonOx)\ **Post date:** [Mars 1, 2021, 6:44 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/7 "2021-03-01T18:44:01Z")
Allez y moi je vous regarde 😅 Moment ça doit être dans mes cordes EDIT: Le component react ne supporte pas dayjs 😕 > **[GitHub - jquense/react-big-calendar: gcal/outlook like calendar component](https://github.com/jquense/react-big-calendar#localization-and-date-formatting)** > > gcal/outlook like calendar component. Contribute to jquense/react-big-calendar development by creating an account on GitHub. ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [Mars 1, 2021, 10:14 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/8 "2021-03-01T22:14:02Z")
Et autre sujet mais assez lié, nous avons des dépendances avec des failles de sécurité de niveau `high` (12 front et 4 back). Je sais que la plupart des installations ne sont pas ouvertes sur le web mais je pense que c’est mieux de mettre à jour ces dépendances. Je pense que ça vaut le coup d’activer DependaBot : [Enabling and disabling version updates - GitHub Docs](https://docs.github.com/en/github/administering-a-repository/enabling-and-disabling-version-updates#enabling-github-dependabot-version-updates) ---
**Author:** ![AlexTrovato](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/alextrovato/32/10705_2.png) [@AlexTrovato](https://community.gladysassistant.com/u/AlexTrovato)\ **Post date:** [Mars 2, 2021, 6:26 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/9 "2021-03-02T06:26:37Z")
Lol tu trouves tjs une excuse pour ne pas faire !! 😛 ---
**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\ **Post date:** [Mars 2, 2021, 7:14 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/10 "2021-03-02T07:14:39Z")
> [@cicoub13](#): > > Et autre sujet mais assez lié, nous avons des dépendances avec des failles de sécurité de niveau `high` (12 front et 4 back). Je sais que la plupart des installations ne sont pas ouvertes sur le web mais je pense que c’est mieux de mettre à jour ces dépendances. 10000% pour ! Automatiser à minima la recherche de vulns dans le code et limite le configurer en bloquant sur les PR c’est une bonne idée pour s’assurer d’un niveau de sécurité minimum. ---
**Author:** ![VonOx](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/vonox/32/10128_2.png) [@VonOx](https://community.gladysassistant.com/u/VonOx)\ **Post date:** [Mars 2, 2021, 7:32 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/11 "2021-03-02T07:32:11Z")
Il faut les tests avant je pense ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 2, 2021, 1:27 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/12 "2021-03-02T13:27:01Z")
> [@AlexTrovato](#): > > @pierre-gilles je pense en effet que c’est nécessaire, et que c’est même quelque chose qu’il faut faire « au jour le jour » et éviter d’attendre 6 mois pour le faire. Je suis d’accord pour la maintenance générale, c’est au jour le jour 🙂 (version de node, upgrade mineurs/patch des dépendances, qualité de code). Après pour les changements majeures qui n’apportent rien à l’utilisateur/au projet, je ne suis pas forcément pour la course au dépendances. On a quand même des moyens très limité sur le projet, et franchement si tu suis absolument toutes les dépendances en mettant à jour dès qu’une nouvelle sort (je ne parle pas des mises à jour de sécurité), bah tu ne développe plus. Sequelize/tabler/etc… ils ont des rythmes de mise à jour breaking très supérieur à ce qu’on serait capable d’absorber au quotidien. Pour ça que pour ces mises à jour, il faut faire le pour et le contre et évaluer si les pour sont supérieur au temps qu’on pourrait passer sur d’autres fonctionnalités « interne » à Gladys… 🙂 > [@cicoub13](#): > > Oui, mais je pense que les changements Front majeurs sont difficiles aujourd’hui car 0 tests. Même remarque pour unistore un peu plus bas. Je suis d’accord! > [@AlexTrovato](#): > > On en avait déjà parlé, et si je me souviens bien, on avait mentionné [https://www.cypress.io/](https://www.cypress.io/) > > Je pense qu’on va devoir y passer. > > Le top serait donc qu’on se dispatch les tâches, et rien n’empêche de commencer les migrations sans les tests cypress. Je suis chaud pour qu’on se mette à Cypress 🙂 > [@AlexTrovato](#): > > je veux bien me lancer sur cypress, au moins histoire de poser les bases et introduire les tests sur le « core » (il ne faudra pas être pressé, c’est une découverte pour moi) . Je pense que personne ici n’a jamais fais de Cypress, donc limite il faudrait avancer ensemble. Si tu veux regarder pour faire un POC, et ensuite on factorisera tous ensemble ? Je peux regarder aussi de mon côté 🙂 > [@VonOx](#): > > EDIT: Le component react ne supporte pas dayjs 😕 ah merde? C’est sur à 100% ? On pourrait soit proposer une PR, soit trouver un hack pour que ça marche… sinon globalize ou date-fns c’est moins pire que moment > [@cicoub13](#): > > Et autre sujet mais assez lié, nous avons des dépendances avec des failles de sécurité de niveau `high` (12 front et 4 back). Je sais que la plupart des installations ne sont pas ouvertes sur le web mais je pense que c’est mieux de mettre à jour ces dépendances J’ai vu, c’est aussi le but de ce point stabilité 🙂 > [@cicoub13](#): > > Je pense que ça vaut le coup d’activer DependaBot J’ai déjà dependabot activé sur le repo pour la partie « notifications », après pour la partie « PR automatisée » je suis plutôt contre. Sur un projet de l’échelle de Gladys, ça fait des dizaines/centaines de PR par jour, ça remplit complètement les PRs et le CI, et en fait c’est juste impossible d’aller aussi vite que lui 😛 > [@lmilcent](#): > > limite le configurer en bloquant sur les PR ça je suis pour 🙂 il faut mettre un `npm audit` dans la CI et bloquer uniquement sur les failles « high/critical » 🙂 ---
**Author:** ![AlexTrovato](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/alextrovato/32/10705_2.png) [@AlexTrovato](https://community.gladysassistant.com/u/AlexTrovato)\ **Post date:** [Mars 2, 2021, 7:03 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/13 "2021-03-02T19:03:37Z")
Ok j’ai déjà commencé le POC pour cypress, je pense que je vais faire quelques pages (login, dashboard, inscription) pour voir les différents aspects, et l’intégration ci github action certainement. Je vais tenter de tenir un rapport pour les questions ouvertes et autres points de difficulté rencontrés. Dès que j’ai un petit quelque chose, je partagerai pour qu’on en discute. ---
**Author:** ![AlexTrovato](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/alextrovato/32/10705_2.png) [@AlexTrovato](https://community.gladysassistant.com/u/AlexTrovato)\ **Post date:** [Mars 5, 2021, 5:40 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/14 "2021-03-05T17:40:42Z")
Bonsoir à tous, si certains veulent jouer ou commenter la mise en place de cypress : [https://github.com/GladysAssistant/Gladys/pull/1086](https://github.com/GladysAssistant/Gladys/pull/1086) La doc (qui évolue avec l’expérimentation) : > **[Cypress pour Gladys](https://docs.google.com/document/d/1VXJHENNGTYVgn9PI8hOI-t_24YWPSHucfAnO0jwhTec/edit?usp=sharing)** > > Cypress pour Gladys Lien de la documentation : https://docs.cypress.io/ Les questions / propositions sur les choix à déterminer sont à la fin du fichier. Arborescence des tests L’installation du module via npm install --save-dev cypress génère un... Et la je joue avec les actions Github pour automatiser la chose, c’est plutot pas mal, mais biensur, ça va rallonger le temps de build : > **[Build software better, together](https://github.com/atrovato/Gladys/runs/2041711952?check_suite_focus=true)** > > GitHub is where people build software. More than 65 million people use GitHub to discover, fork, and contribute to over 200 million projects. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 8, 2021, 1:18 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/15 "2021-03-08T01:18:21Z")
Salut @AlexTrovato ! Super boulot, je mets ici mes réponses à tes questions ouvertes : > 1. Choix du nommage des fichiers de tests : > 2. je pense qu’il ne faut pas nommer tous nos fichier index.js mais tenter de découpage les cas fonctionnels par fichier > 3. 1 fichier par cas ? (login\_success.js / login\_error.js) Un fichier par cas ça me semble énorme, tu trouves pas ? Côté serveur on fait un fichier de test par fichier dans Gladys, en général un fichier par fonction. Et ensuite dans le fichier on fait un cas par cas à tester, ça me parait plus clean, sinon ça va faire beaucoup de fichiers non ? > 1. snake\_case vs camelCase ? Côté front c’est du CamelCase avec la première lettre en majuscule, je pense qu’il faut garder la même règle pour les fichiers de tests. > 1. Démarrer le front en développement ou production ? J’ai pas l’expérience de Cypress pour savoir quelle est la best practice la dessus ^^ > 1. Démarrer également le serveur ? Ou mocker les réponses > 2. Si on démarre le serveur, on ne peut pas tester les services / intégrations > 3. Si on mock les réponses, plus de travail, maintenance plus lourde Bonne question ça. Pour moi l’avantage de mocker ça serait effectivement pour les services, après l’inconvénient c’est que potentiellement si une route d’API change dans le code backend, et que les mocks sont pas mise à jour, bah les tests du front vont passer alors qu’en fait dans la vrai vie ça pète. C’est moins end-to-end quoi Peut-être qu’une approche « hybride » serait possible ? On mock tout ce qui est services, et l’API de Gladys core (login, etc…) n’est pas mockée comme ça on est certain que les routes critiques (login, forgot password, signup) fonctionnent bien en E2E. > 1. Comment détecter que le front est prêt pour démarrer les tests automatiquement ? Là dessus j’ai pas l’expérience de Cypress, il va falloir enquêter ^^ > 1. Comment gérer “proprement” la langue du navigateur ? Il doit y avoir un moyen dans cypress non? ---
**Author:** ![wazalop](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/wazalop/32/6154_2.png) [@wazalop](https://community.gladysassistant.com/u/wazalop)\ **Post date:** [Mars 8, 2021, 5:13 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/16 "2021-03-08T17:13:03Z")
Salut, > [@pierre-gilles](#): > > Bonne question ça. Pour moi l’avantage de mocker ça serait effectivement pour les services, après l’inconvénient c’est que potentiellement si une route d’API change dans le code backend, et que les mocks sont pas mise à jour, bah les tests du front vont passer alors qu’en fait dans la vrai vie ça pète. C’est moins end-to-end quoi > > Peut-être qu’une approche « hybride » serait possible ? > > On mock tout ce qui est services, et l’API de Gladys core (login, etc…) n’est pas mockée comme ça on est certain que les routes critiques (login, forgot password, signup) fonctionnent bien en E2E. je ne connais pas vraiment cypress, mais si le but est de faire des test E2E il faut effectivement laisser les api derrières puisque le principe est de tester l’assemblage des differentes briques. Si le but est de faire des test plus unitaire coté front, alors il vaut mieux tout mocker même l’api core je pense qu’il faut les 2 type de tests, les E2E qui permettent effectivement de vérifier que toutes les briques fonctionnent correctement entre elles, et les test unitaires qui permettent de savoir si un composant a un problème ou non. Pour les tests unitaire, c’est qu’en gros on vérifie le comportement du composant selon tous les cas possible. Ca implique de tester les props qu’on lui passe si un composant attend un prop number on test avec un number puis un string puis un null, etc… pour vérifier que ca gère bien tous les cas, si il y a des events on vérifie que ceux ci soit bien appelé, soit correctement appelé (un click event doit être appelé qu’une fois, etc…), etc… on test aussi les changement de states lorsque nécessaire (en gros un bouton qui aurai un state loading il faut vérifier que lorsque le state loading est actif le bouton soit dans la bonne représentation, il a bien la classe loading par exemple, etc…) Ce sont les test les plus chiant a faire, sur des petit composant ca va vite, des qu’il s’agit d’un composant plus complexe c’est le bordel ^^ il semble y avoir plusieurs possibilité pour gérer ces tests, dans la doc preact il parle d’enzyme ou de preact testing library qui permet de faire les test unitaire de façon plus simple mais bon ^^ ( [Unit Testing with Enzyme – Preact Guide](https://preactjs.com/guide/v10/unit-testing-with-enzyme) ou [Testing with Preact Testing Library – Preact Guide](https://preactjs.com/guide/v10/preact-testing-library)) ---
**Author:** ![bertrandda](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bertrandda/32/5929_2.png) [@bertrandda](https://community.gladysassistant.com/u/bertrandda)\ **Post date:** [Mars 8, 2021, 9:57 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/17 "2021-03-08T21:57:50Z")
Je me suis occupé de supprimer `moment` du front. J’ai changé par dayjs fallait charger en plus les 2 plugins `localizedFormat` et `localeData`, l’API étant assez proche de moment, ça fonctionne bien. Si sur le long terme on voit des problèmes apparaitre j’ai vu qu’on utilisait date-fns dans `ScheduledTriger` qui est aussi compatible `react-big-calendar` on pourra se rediriger là dessus. [https://github.com/GladysAssistant/Gladys/pull/1092](https://github.com/GladysAssistant/Gladys/pull/1092) ---
**Author:** ![AlexTrovato](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/alextrovato/32/10705_2.png) [@AlexTrovato](https://community.gladysassistant.com/u/AlexTrovato)\ **Post date:** [Mars 9, 2021, 8:15 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/18 "2021-03-09T20:15:33Z")
> 1. Démarrer également le serveur ? Ou mocker les réponses > 2. Si on démarre le serveur, on ne peut pas tester les services / intégrations > 3. Si on mock les réponses, plus de travail, maintenance plus lourde Je te suis pour tester l’intégration sur le core et mocker les services (au moins pour les cas en succés), on peut facilement mixer les 2. Je vais compléter la PR actuelle pour fournir un exemple des 2 cas. Du coup, je pense que ça permet de tester en mode « production », afin de valider la cible, en mode « e2e », sauf pour les services. > 1. Comment détecter que le front est prêt pour démarrer les tests automatiquement ? Github actions sait le faire, il y a l’option dans la PR CI. > 1. Comment gérer “proprement” la langue du navigateur ? Je pense que ma question est plutôt : doit-on faire des tests sur les libellés ? ça risque d’être assez lourd. Mais pour valider les messages d’erreur selon les cas, ça peut être utile. Sinon ce sera par variable / config d’exécution. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 10, 2021, 1:19 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/19 "2021-03-10T01:19:42Z")
> [@AlexTrovato](#): > > Je te suis pour tester l’intégration sur le core et mocker les services (au moins pour les cas en succés), on peut facilement mixer les 2. > Je vais compléter la PR actuelle pour fournir un exemple des 2 cas. > Du coup, je pense que ça permet de tester en mode « production », afin de valider la cible, en mode « e2e », sauf pour les services. Ok, bonne idée ! > [@AlexTrovato](#): > > Github actions sait le faire, il y a l’option dans la PR CI. Nice 🙂 > [@AlexTrovato](#): > > Je pense que ma question est plutôt : doit-on faire des tests sur les libellés ? ça risque d’être assez lourd. Mais pour valider les messages d’erreur selon les cas, ça peut être utile. > Sinon ce sera par variable / config d’exécution. ça dépend des cas je dirais. Effectivement pour les erreurs ça pourrait être bien. Surtout pour certaines pages « critiques » (login, signup) ou il faut vraiment bétonner. Sinon, pas la peine, ça risque d’être redondant et lourd 🙂 ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 22, 2021, 3:25 UTC](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121/20 "2021-03-22T03:25:07Z")
@bertrandda je viens de remarquer que le service Caldav utilise moment côté backend, ça serait cool de changer aussi ici 🙂 [Page suivante](https://community.gladysassistant.com/t/point-stabilite-mise-a-jour-des-dependance-qualite-de-code/6121.md?page=2)