Alors comment faire en sorte que vos collègues (vous n'êtes jamais le problème et je suis fier de vous) fassent des meilleurs tests ? Vous pouvez introduire des règles ESLint qui s'en chargeront pour vous.
Un bon test front est un test orienté utilisateur : c'est à dire qu'il teste ce qui a de la valeur pour l'utilisateur. L'utilisateur ne veut pas se soucier de si votre setState aÉtéCalledTimes(1), il veut savoir si quand il clique sur le bouton il se passe quelque chose pour lui.
Nouveau souci : le coverage. Le sacro-saint coverage c'est très joli dans les slides de la revue de sprint mais malheureusement tout ce qu'il vous dit c'est que votre test est passé par là. Ça ne vous dit absolument pas si le test lui-même vérifie des choses pertinentes.
Heureusement vous pouvez réparer votre snapshot en une ligne dans le terminal. Le problème avec ça c'est que vous allez avoir tellement l'habitude que vos tests pètent que vous risquez de laisser passer plein de faux positifs.
ParisJS numéro 110 chez @Eleven_Labs ça commence très bientôt ! On revient de vacances donc il nous faut un moment pour tout bien relancer mais on fait au plus vite !
Au programme:
→ Elise Recejac : Comment améliorer vos tests front avec Testing Library
→ Alix Bou : Arrêtez d'embaucher des seniors, faites devenir vos juniors plus forts qu'eux !
→ @porteneuve : L'asynchrone en JS sans le cringe
APÉRO JS
DEMAIN 19H
L'Appartement Saint-Martin, Strasbourg Saint-Denis
Soyez nombreux (mais pas trop, le bar est pas gigantesque) (consos non-incluses) (rien n'est inclus d'ailleurs) (on n'est littéralement pas le Club Med)
Apparemment Vercel à fait un template tout fait pour vous aider à bricoler des trucs avec l'API d'OpenAI, si vous voulez vous amuser un peu avec des LLM. On sait jamais. Ça a peut-être un avenir ces trucs-là. Qui sait ? Pas moi.
J'ai apparemment loupé le moment où il a fait une machine à espresso en React.
Je vous ai déjà dit qu'on a des replays qui arrivent bientôt ? On a des replays qui arrivent bientôt.