Post de Laravel Cameroun

Bonjour 😍 C’est quoi Cypress ? Cypress est un framework d’automatisation de tests basé sur du JavaScript. Il adopte une approche différente par rapport aux autres frameworks de tests automatiques. Cypress est rapide, interactif et fiable. Il vous permet d’automatiser plusieurs types de tests comme : tests End to End, Tests d’intégration, tests unitaires et tests d’API. Plongez dans son univers et vous serez ébloui, il suffit de commencer 😉

🚮 Byebye Jest, Mocha, Vitest, et consorts côté Node... ...bientôt même avec TS et sans ajouter 15 modules. 😵 WTF ?! Rien d'exceptionnel, Deno et Bun le font déjà, mais ça arrive petit à petit sur Node. • Ça fait plaisir de voir la toolbelt native s'étoffer. • Ça fait plaisir de faire maigrir les node_modules. 📝 On a donc : - Node 18 qui a introduit le test runner experimental - Node 20 qui a introduit le test runner stabilisé - Node 22 qui a introduit le flag experimental-strip-types (dont j'ai parlé dans un autre post) et l'API du test runner s'enrichit. 💪 Résultat ? - Tu peux exécuter ton code TS directement avec Node sans tooling spécifique. ET - Tu peux exécuter tes tests TS directement avec Node sans tooling spécifique. 🎁 Que nous réservera Node 24 ? J'espère encore plus de stabilisation de l'API test runner, comme le watch mode. Ça fait longtemps que je suis les avancées du test runner (pour la sobriété, pour les perfs, pour la DX) et toi ? Qu'en penses-tu ? ___ Tu me découvres ou me redécouvres avec ce post ? 🛠️ Pendant tout le mois d'octobre, je publie un post par jour autour de NodeJS, TypeScript et d'Architecture Logicielle. #NodeJS #TypeScript #OctoberChallenge

Red-Green-Refactor aujourd'hui j'ai continué avec le refactoring du test unitaire du save tout en m'assurant que mon test reste au vert demain je continue avec le feature test #100DayOfCodes #Day002 #tdd #nestJs #typescript

🎬 Express - Test d'Intégration avec SuperTest Les tests unitaires permettent de tester des unités fonctionnelles et offrent aux développeurs des retours rapides pendant la phase de développement. Malgré leur intérêt, les tests unitaires ne couvrent pas tous les scénarios d'utilisation d'une application. Ils ne garantissent pas que, une fois assemblés, les composants testés individuellement fonctionneront comme prévu. C'est là qu'interviennent les tests d'intégration. Les tests d'intégration assurent que les différents composants d'une application interagissent correctement et fonctionnent ensemble comme souhaité. Dans notre cas, puisque nous développons une API, l'objectif de nos tests d'intégration est de vérifier que, lors des requêtes utilisateur : - Des validations sont effectuées sur les données envoyées, et que le serveur répond avec les bonnes réponses et les bons statuts HTTP. - Lorsqu'une requête contient des données invalides, un message d'erreur descriptif est retourné à l'utilisateur avec le bon statut HTTP. - Lorsqu'une requête contient des données valides, le serveur exécute correctement l'action demandée (création, mise à jour, suppression, récupération de données) et retourne la réponse attendue avec le bon statut HTTP. Par exemple, pour une requête d'authentification, nous vérifions que : - Une erreur 400 est retournée lorsque l'email ou le mot de passe n'est pas renseigné. - Une erreur 401 est retournée lorsque l'email et le mot de passe sont renseignés mais ne correspondent pas à un utilisateur existant. - Une réponse 200 est retournée lorsqu'une combinaison valide d'email et de mot de passe est fournie, et que le corps de la réponse contient un token d'authentification. Cela nous permet de disposer de tests qui nous évitent de passer par Postman/Insomnia après chaque modification majeure, ce qui représente un gain de temps tout en garantissant la qualité de notre API. Comme dans la vidéo précédente sur les tests unitaires, nous utiliserons le module de test et d'assertion natif de Node.js, auquel nous associerons Supertest, un module NPM permettant de réaliser des tests d'intégration sur des applications développées avec Express.js. Vous trouverez en commentaire, le lien de la vidéo complète. RDV jeudi prochain pour une nouvelle vidéo. 🧠 Stay Curious!! #devPropulsor #ExpressJs #TypeScript #NodeJs #integrationTest #APITest #SuperTest #quality

Le message des commits... un dilemme hein 😆 Tout développeur ayant déjà eu à travailler avec l'outil git a rencontré à un moment ou un autre ce "syndrome du commit blanc". une solution serait de se donner à soit, à une équipe ou encore pour un projet donné des conventions de nommage. Par exemple, les commits qui ajoute une fonctionnalité doivent commencés par "feat:" suivi du nom de la fonctionnalité ajoutée, de même que pour les réparations 🛠️ "fix:", ou encore "test:" ⚙️ pour ceux qui font des test unitaires. à partir de cela il devient facile de nommer ses commits.

Découvre la magie de Git bisect ! ✨ Vous êtes-vous déjà retrouvé à chercher la petite bête qui a introduit un bug dans votre code ? Git bisect est votre nouvel allié pour résoudre ce genre de casse-tête ! 🎯 Qu'est-ce que Git bisect ? C'est une commande puissante qui utilise un algorithme de recherche binaire pour identifier le commit exact qui a introduit un bug dans votre historique Git. C'est comme une sorte de jeu de devinettes où Git vous propose des commits à tester, et vous devez indiquer si le bug est présent ou non. Cas concret : Imaginez que votre application web, qui fonctionnait parfaitement il y a une semaine, commence à planter de manière aléatoire. Au lieu de passer des heures à examiner ligne par ligne chaque modification, vous pouvez utiliser git bisect pour identifier rapidement le coupable. 1️⃣ Définir les bornes : Vous identifiez un commit "bon" (où l'application fonctionnait) et un commit "mauvais" (où le bug est présent). 2️⃣ Lancer la recherche : git bisect start git bisect bad <mauvais-commit> git bisect good <bon-commmit> 3️⃣ Tester et itérer : Git vous propose un commit intermédiaire. Vous testez votre application et indiquez si le bug est présent ou non. 4️⃣ Trouver le coupable : Git affine la recherche à chaque itération jusqu'à ce qu'il identifie le commit exact qui a introduit le bug. 💡Les avantages de Git bisect : ✅️ Gain de temps considérable ✅️ Identification du commit fautif avec certitude ✅️ Facilité d'utilisation

🎯 Selenium, Cypress ou Playwright : Quel outil de test choisir ? Dans le domaine des tests automatisés, choisir le bon framework est essentiel pour garantir l'efficacité et la qualité des tests end-to-end (E2E). Selenium, Cypress et Playwright se distinguent chacun par leurs caractéristiques et leurs avantages : Selenium offre une grande flexibilité et supporte plusieurs navigateurs et langages, mais nécessite souvent des configurations complexes. Cypress brille par sa simplicité et sa rapidité, mais reste limité aux tests front-end modernes. Playwright, quant à lui, allie modernité et robustesse avec des fonctionnalités natives comme les tests mobiles et les exécutions parallèles. 👉 Quel outil utilisez-vous ou recommandez-vous pour vos projets ? Partagez votre expérience en commentaire ! By : Ihsane Laalioui

Des règles de lint "prefer-signals" bientôt disponibles dans la prochaine version d'angular-eslint (19). Pour migrer vos composants petit à petit et ne pas rajouter de vieil Input/Outputs dans vos bases de code #angular https://lnkd.in/eU8srrin

🧪 Simplifiez vos tests avec @ExtendWith(MockitoExtension.class) 🛠️ Dans mes différents projets, j’ai remarqué que les tests unitaires avec Mockito deviennent encore plus intuitifs grâce à l’annotation @ExtendWith(MockitoExtension.class).   Si vous travaillez avec JUnit 5 cette extension permet de tirer parti des fonctionnalités avancées de Mockito. Pourquoi utiliser @ExtendWith(MockitoExtension.class) ?  Mockito permet d’isoler vos classes et simuler les dépendances, mais son intégration avec JUnit 5 via l’extension MockitoExtension permet d’automatiser les tâches répétitives, comme l’initialisation des mocks. 🔧 Avantages  :  Automatisation de l’initialisation : plus besoin d'appeler MockitoAnnotations.openMocks(this) manuellement.  Injection simplifiée : utilisez simplement @Mock ou @InjectMocks, et tout est configuré automatiquement.  Clarté du code : vos tests sont plus lisibles et contiennent moins de configuration    #Mockito #JUnit5 #Testing #CleanCode #Oniryx #IT #ICT #BlacksheepTribes 

3 principes qui ont transformé mes composants React à jamais... Je review plusieurs PR par semaine, et je vois TOUJOURS les mêmes erreurs. Voici les règles qui ont révolutionné la qualité de notre code: Principe 1: Single Responsibility ✨ Un composant = Une responsabilité ✨ Max 100 lignes de code ✨ Extraction systématique des hooks personnalisés ❌ Exit les composants qui font tout ! Principe 2: La règle du sandwich 🥪 ✨ Niveau 1: Les composants containers (logique) ✨ Niveau 2: Les composants métier (features) ✨ Niveau 3: Les composants UI (présentation) Résultat ? Notre temps de debug a été divisé par 2 ! Principe 3: La règle des props ✨ Maximum 5 props par composant ✨ Des noms explicites (exit les data1, data2...) ✨ Toujours des valeurs par défaut ❌ Plus de props = plus de confusion 🎯 Pro tip: Créez une checklist de review basée sur ces principes. Notre taux de réussite aux QA est passé de 65% à 92% ! La question du jour: quel est VOTRE critère numéro 1 pour juger un bon composant React ? 👇 #React #CleanCode #WebDev #DeveloppeurWeb