Mise en place de tests automatisés

[nhumblot]

Il pourrait être intéressant de tester sur chaque PR que le build est vert et mettre en place un cadre pour exécuter des tests unitaires.

Ce projet utilise déjà GitHub Actions pour effectuer le déploiement, on pourrait le paramétrer pour également tester le build sur les PRs.

Le framework pour exécuter les tests unitaires est à définir.

[fcamblor]

Oui, j'ai déjà commencé à un peu regarder comment outiller les tests unitaires avec lit-element & vite, ça ne paraît pas trivial pour le moment.

Mais je suis d'accord que si on pouvait avoir une url dédiée à chaque PR, par exemple via du Firebase hosting, ce serait top !

[fcamblor]

@nicolinuxfr est-ce que tu aurais moyen de customiser un peu le déploiement actuel avec le comportement suivant :

• Changements sur main : on change rien de ce qu'on a actuellement, build + déploiement automatisé sur l'environnement de prod
• Changement sur n'importe qu'elle autre branche (*) : build + déploiement automatisé sur un environnement de test du type https://rooturl/<nom_branche>/ et en utilisant ce que j'avais mis en place pour configurer les URL base (passage de la variable d'environnement BASE_URL valorisée avec le nom de la branche)

(*) Si tu n'as pas un espace infini (bon, sachant que les assets font environ 1-2Mo donc c'est pas énormissime), on pourrait imaginer ne déployer que des branches qui matchent un certain pattern (ex: deploy-feature-xxx)

Ça serait juste ultra utile pour tester :-)

[nicolinuxfr]

Ok j’essaie de vous faire ça après manger, je finirai peut-être ce soir parce que je suis en plein déménagement la.

Le nom de domaine de base, peu importe on est d’accord ?

[fcamblor]

Oui peu importe le nom de domaine :-)

[nicolinuxfr]

Du coup ce sera https://dev.vitemado.se/ parce que j’aime bien ce domaine trop malin pour son bien. 🙂

Tout est prêt côté serveur, est-ce que je peux vous laisser finaliser la GitHub Actions ? Reprenez celle de la branche main, mais avec comme chemin $DEPLOY_PATH_DEV suivi de la branche. J’ai mis le slash final dans la clé privée, et je connais pas la syntaxe de Github par cœur, mais dans l’idée ça donnerait $DEPLOY_PATH_DEV{nom_branche} par exemple.

Si ça marche pas, dites-le ici et je corrige ce soir.

[nicolinuxfr]

Ah ben je vois que ça n’a pas avancé. Je tente de vous mettre ça en place sans tout casser…

[nicolinuxfr]

Je bloque sur la dernière ligne droite, mais j’ai pas le temps là de regarder. J’ai ouvert une PR en tout cas : #54

[fcamblor]

Étant donné qu'on a taclé la partie "déploiement automatisé", j'ai pris la liberté de renommer l'issue pour me focaliser sur les aspects de test automatisés ;-)

[Floby]

Visiblement
C'est soit Jest+Electron : https://www.ninkovic.dev/blog/2020/testing-web-components-with-jest-and-lit-element
Soit Mocha+WCT : https://www.npmjs.com/package/web-component-tester

[Floby]

j'ai trouvé cet article qui parle de faire du jest+lit-html, https://matthias-kainer.de/blog/posts/testing-webcomponents-with-jest-and-dom-testing-tools/
J'ai pas tout pigé

[Floby]

ok, j'ai pigé et maintenant je pense que c'est the way to go :)

• testing-library c'est the shit pour tester des composants front sans se prendre la tête avec des tests couplés à l'implem/la lib
• jest c'est the shit pour les tests front, notamment parce qu'il isole dans un espace de noms et que comme les tests front c'est messy, c'est toujours mieux. le parallélisme, meh c'est sympa. Aussi il y a les snapshots qui peuvent être utiles
• de ce qu'il décrit, il y a quelques subtilités à cause du shadow dom mais c'est largement gérable.

Je vais essayer de voir pour mettre ça en place sur #148 parce que j'ai besion de tests de caractérisation sur les composants existants (et que j'ai déjà mis du jest pour le code de base)

[Floby]

ma que bella 😚👌