Trending

#softwarecraftsmanship

Latest posts tagged with #softwarecraftsmanship on Bluesky

Latest Top

Posts tagged #softwarecraftsmanship

Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
1 day ago
Post image

Joshua Angolano, Teresa Hill-Rush, Jon Graf & Sarah Little present on Practical Agile this July at Nebraska.Code().

nebraskacode.amegala.com

#PracticalAgile #SoftwareCraftsmanship #ANNIEModel #Agile #Nebraska #SoftwareDev #Programming #WomenWhoCode #WomenInSTEM #HeartlandTech #Midwest

2 1 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
2 days ago
Post image

Isaac Levin, Barry Stahl, Joseph Guadagno & Cory House have full-day Workshops at Nebraska.Code() in July.

nebraskacode.amegala.com

#ASPNETCore #RESTfulServices #Blazor #FrontEnd #Cloud #MicrosoftTechnology #DynamicProgramming #Nebraska #GeneticAlgorithms #AI #SoftwareCraftsmanship #TechWorkshop

3 0 0 0
sbanas.bsky.social
sbanas.bsky.social
@sbanas.bsky.social
1 month ago
Thinking Beyond Syntax: The Art of Code
Thinking Beyond Syntax: The Art of Code YouTube video by Manning Publications

Thinking Beyond Syntax: The Art of Code — AI can generate code, but humans give it intent, taste, and meaning.
👉 hubs.la/Q042g7yP0
📘 Save 40%: WATCHBANAS40
www.youtube.com/watch?v=Fd_p...
#Java #SoftwareCraftsmanship #CleanCode #TheArtOfCode #ManningBooks #IA @manning.com

3 2 0 0
sbanas.bsky.social
sbanas.bsky.social
@sbanas.bsky.social
2 months ago
Video

Behind every line of code, there’s more than logic.
There’s judgment, creativity… and a bit of craft ✨
www.manning.com/books/the-ar...

#SoftwareCraftsmanship #CodeQuality #DevLife

2 1 0 0
sbanas.bsky.social
sbanas.bsky.social
@sbanas.bsky.social
2 months ago
Post image

Ravie d’annoncer que je participerai à @mixitconf.org 🎉
Merci💙au comité de sélection d’avoir choisi mon talk
Il était une fois le code : du Clean Code au Narrative Code
Hâte de partager et d’échanger autour du craft et de la qualité du code.

#MiXiT #SoftwareCraftsmanship #CleanCode #CodeQuality

3 1 0 0
sbanas.bsky.social
sbanas.bsky.social
@sbanas.bsky.social
2 months ago
Preview
The Art of Code - Sandrine Banas Software development is an inherently creative activity that takes technical skill as well as artistry and craftsmanship. This unique book shows you how to improve the performance of your applications...

First post here 👋
I’m the author of The Art of Code (Manning), a book on modern software craftsmanship and human judgment in the age of AI. Happy to join the conversation and learn with you! 💙
www.manning.com/books/the-ar...
#SoftwareCraftsmanship #SoftwareEngineering #Developers #HumanJudgment

4 1 0 0
geecon
geecon
@geecon.bsky.social
4 months ago
Post image

#GeeCON is now open for CFP submissions for the 2026 edition, happening on May 14–15! Step in, share your story, and inspire the community — submit your talk proposal on #Java, #AI, #SoftwareEngineering, #Microservices, #Cloud, #SoftwareCraftsmanship, or #Agile. 2026.geecon.org/cfp/

6 3 0 0
@claudiolassala.bsky.social
5 months ago
Preview
The Timeless Habits of Effective Remote Teams In April 2020, just a few weeks into the COVID-19 pandemic, George and I revisited a presentation we had given initially around 2010 at the Houston TechFest. At that time, everyone was suddenly wor…

15 years later, remote teamwork still runs on empathy, connection, and good habits — not tools.
Just rewatched a 2020 convo George & I had about our old 2010 talk.
Still true in 2025.
🧠 Read & watch: lassala.net/2025/11/05/t...

#softwarecraftsmanship #teams #communication

0 0 0 0
Fahim khan
Fahim khan
@morfes.bsky.social
7 months ago

"Every line of code represents an ethical and moral decision."
—Robert C. Martin (“Uncle Bob”), from the chapter "Who Are We?" in We, Programmers: A Chronicle of Coders from Ada to AI
#CodeEthics #SoftwareCraftsmanship #UncleBob #WeProgrammers

1 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
8 months ago
Post image

Nebraska.Code() Breakout Sessions start Thursday July 24th and run through Friday July 25th!

nebraskacode.amegala.com

#CareerProgression #CloudComputing #DevOps #TechTalks #EmergingTechnology #PracticalAgile #FrontEndDevelopment #SoftwareCraftsmanship #AI #Nebraska #TechnologyConference

1 1 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
8 months ago
Post image

NEXT WEEK is Nebraska.Code()!
Join us for the largest software development conference in the Heartland.

nebraskacode.amegala.com

#softwareplanning #DevOps #development #deployment #CareerProgression #FrontEnd #CloudComputing #EmergingTech #Agile #SoftwareCraftsmanship #AI #Nebraska

2 1 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
8 months ago
Post image

THREE DAYS LEFT until Nebraska.Code()!

nebraskacode.amegala.com

#Frontend #OpenSource #EmergingTrends #PracticalAgile #DevOps #Security #Nebraska #CareerDevelopment #SoftwareCraftsmanship

2 1 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
8 months ago
Post image

ONE WEEK LEFT until Nebraska.Code()!

nebraskacode.amegala.com

#CareerProgression #CloudComputing #DevOps #EmergingTechnology #FrontEnd #PracticalAgile #SoftwareCraftsmanship #AI #Nebraska

3 1 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
8 months ago
Post image

Time is running out to register for Nebraska.Code!

nebraskacode.amegala.com

#CareerProgression #CloudComputing #DevOps #EmergingTechnology #FrontEnd #PracticalAgile #SoftwareCraftsmanship #AI #Nebraska

3 1 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Jerry Nixon, Spencer Schneidenbach, Jonathan "J." Tower, and Mike Benkovich have Sessions on Software Craftsmanship at Nebraska.Code().

nebraskacode.amegala.com

#SoftwareCraftsmanship #DatabasePatterns #APIs #ASPNET #Identity #Nebraska #TechConference #softwaredevelopment #softwareengineering

2 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Jeremy Clark, David Handlos, Arthur Doler, and Erissa Duvall have Sessions on Software Craftsmanship at Nebraska.Code().

nebraskacode.amegala.com

#Coding #CrisisCommunication #CodeArcheology #AccessibleGaming #GitHub #Aviture #SoftwareCraftsmanship #TechConf #Nebraska #FNBO #programming #developer

3 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Matthew Watt, David Kerber, Lorenzo Gallegos, and Mitchel Sellers present on Software Craftsmanship at Nebraska.Code().

nebraskacode.amegala.com

#SoftwareCraftsmanship #FunctionalProgramming #TechStack #Secure #Coding #Code #TechConf #Nebraska #Software #Programming #Heartland #lincolnnebraska

1 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Jeren Hicks, Tyler Morten, Jerry Nixon, and Caleb Larsen have Sessions on Software Craftsmanship at Nebraska.Code().

nebraskacode.amegala.com

#SoftwareCraftsmanship #Programming #Refactoring #Nebraska #TechConf #Lincoln #ContinuousLearning #Aviture #Microsoft #softwareengineering #softwaredev

2 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Ben Ferguson, Scott Bock, and Brandon Suponchick present on Software Craftsmanship in July at Nebraska.Code().

nebraskacode.amegala.com

#SoftwareCraftsmanship #Grafana #Nebraska #Tech #RootCauseAnalysis #OpenTelemetry #softwaredevelopment #softwareengineering #software #DeveloperConference

1 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Rhia Dixon, MBA, Cory House, and Chad Michel have Sessions on Software Craftsmanship at Nebraska.Code().

nebraskacode.amegala.com

#VML #Pluralsight #DontPanicLabs #SoftwareCraftsmanship #Refactoring #TechnologyConference #Nebraska #CoryHouse #RhiaDixon #ChadMichel #Software #DeveloperConference

2 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Jeremy Clark, Kunle Adeleke, Pichaimani Rajesh Kumar, and Matt Williams have Full-Day Workshops this July at Nebraska.Code().

nebraskacode.amegala.com

#CSharp #RAGSolution #AWS #SustainableTech #TechnologyConference #Lincoln #TechWorkshops #Nebraska #SoftwareCraftsmanship #HandsOnLearning

4 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Adrienne Braganza Tacke presents 'Looks GREAT To Me: Getting Past Bare Minimum Code Reviews' July 24th at Nebraska.Code().

nebraskacode.amegala.com

#CodeReviews #SoftwareCraftsmanship #TechnologyConference #Nebraska #Coding #softwaredevelopment #softwareengineering #DevConf #Coding #Metrics

2 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Aaron Grothe, CISSP presents 'What About C/C++' July 24th at Nebraska.Code().

nebraskacode.amegala.com

#CSharp #TechnicalDebt #LegacyCode #CDialects #Cyclone #Trapc #TechConference #Nebraska #SoftwareCraftsmanship #lincolnnebraska #softwaredevelopment #DeveloperConference #developercommunity

2 1 0 0
Eric Yates
Eric Yates
@ericthecurious.bsky.social
9 months ago
Video

Alright, I got distracted by life for a bit. Happens. Especially these days it seems.

Getting back into it, now I've added these hover transitions for desktop users and tightened up styling once again.

How long can I go until I get rid of hello world? 😂

#buildinpublic #softwarecraftsmanship

4 1 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Matt Ruwe presents 'Uncovering Hidden Gems in .NET: Boost Your Development Toolbox' July 25th at Nebraska.Code().

nebraskacode.amegala.com

#DotNet #DevToolbox #Software #Nebraska #SoftwareCraftsmanship #TechConference #Kiewit #SoftwareDevelopment #Nebraska #July2025

2 0 0 0
Naoplay
Naoplay
@naoplay.bsky.social
9 months ago
Post image

APItime revient le 2 juillet à 13h15 pour un épisode dédié aux bonnes pratiques Git et au Software Craftsmanship. 30 min de retours concrets avec Akhara & Maïdine Faye (Carrefour Banque).
👉 Inscription : naoplay.fr/apitime

#APItime #Git #SoftwareCraftsmanship #DevOps

1 1 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
9 months ago
Post image

Brandon Suponchick presents 'Technically....Is That Even Technical Debt?' July 25th at Nebraska.Code().

nebraskacode.amegala.com

#TechnicalDebt #UpdatingLibraries #ChangingPatterns #FixingBugs #lincoln #TechnicalSustainment #ModernizationActivities #SoftwareCraftsmanship #Nebraska #TechConference

3 1 0 0
Forem
Forem
@forem.com.web.brid.gy
10 months ago
Preview
Mock Me If You Can : Guide de Survie des Tests Logiciels # 🧪 Mock Me If You Can : Guide de Survie des Tests Logiciels Ah, les tests. Ce mot magique qui peut transformer un commit innocent en un feu d'artifice rouge dans ton pipeline CI. Tu pensais avoir tout compris ? Détrompe-toi, camarade développeur chevronné. Voici un tour d'horizon **(un peu) technique** , **(légèrement) sarcastique** et **(probablement) pertinent** des principaux types de tests logiciels : * ✅ Tests unitaires (_mockistes_ vs _classicists_) * 🔌 Tests d'intégration * 🧪 Tests end-to-end (E2E) * 🔥 Tests de charge _La fameuse pyramide des tests : moins tu montes, mieux tu dors._ ## 🎬 Bonus : Notre Talk "La Légende des Gardiens du Code" > 🗣️ **Tu préfères regarder plutôt que lire ?** On t'a couvert ! Le **06 juin 2024** , avec mon acolyte **Jeremy Bernard** , on a donné un talk au **DevQuest** sur ce sujet brûlant : les types de tests et la CI/CD qui va avec. ### 🎥 Le Talk en Vidéo 📺 **Regarder "La Légende des Gardiens du Code" sur YouTube** _(Lien disponible prochainement !)_ ### 📊 Les Slides de la Conférence 💾 **Télécharger le PowerPoint de la conférence** _Spoiler alert : On y raconte comment les tests sont les vrais gardiens de votre code... et pourquoi sans eux, c'est l'anarchie totale en production ! 🔥_ ## 🧩 Tests Unitaires : Mockistes vs Classicists — Le Match de Boxe > "Un bon test unitaire isole. Un test unitaire parfait n'existe pas." > > — Un développeur qui a perdu 3 jours à débugger un mock ### 🥊 Camp 1 : Les Mockistes (a.k.a. London School) Tu veux tout contrôler ? Tu adores faire semblant ? Bienvenue chez les **mockistes**. Ici, chaque dépendance est simulée. Tu ne veux pas tester si `fetchData()` accède à une vraie BDD, tu veux juste qu'il _croie_ qu'elle existe. #### ✅ Avantages * Hyper rapide * Super précis : tu sais exactement ce qui est cassé * Isolation complète du code testé #### ❌ Inconvénients * Fragile comme un test PCR dans une boîte chaude * Teste souvent l'implémentation plus que le comportement * Maintenance élevée des mocks ### 🧘‍♂️ Camp 2 : Les Classicists (a.k.a. Chicago School) Tu préfères tester sans te casser la tête à tout mocker ? Tu es **classicist**. Tu laisses les vraies dépendances s'exécuter dans leur contexte logique. #### ✅ Avantages * Teste des comportements réels * Moins de maintenance liée aux mocks #### ❌ Inconvénients * Moins rapide * Plus sujet aux tests flakies * Risque de mauvaise séparation des responsabilités ### 🤯 Le Vrai Dilemme ? * Les **mockistes** valident les _interactions_ * Les **classicists** valident les _résultats_ 👉 **Choisis ton camp, mais reste cohérent.** ## 🔌 Tests d'Intégration : Là où les Bugs naissent > "Ça marche en local, mais en prod c'est l'apocalypse ? Tu fais pas de tests d'intégration, hein ?" Le test d'intégration, c'est le café serré du TDD. Il ne teste pas chaque grain, mais la machine complète. ### ✅ Avantages * Révèle les vrais bugs (ceux qui pètent en prod) * Valide les comportements transverses : transactions, configs, etc. ### ❌ Inconvénients * Lents, très lents * Fragiles si dépendances instables * Requiert souvent un environnement spécifique ou des outils comme **Testcontainers** , **WireMock** , etc. # 🔧 Schéma 1: Test d'Intégration Multi-Couches > _"Quand toutes les couches doivent jouer ensemble... sans se disputer"_ > ┌─────────────────────────────────────────────────────────────┐ │ 🖥️ COUCHE UI (Frontend) ✅ UI répond │ ├─────────────────────────────────────────────────────────────┤ │ • Formulaire de commande │ │ • Saisie produit: "Licorne en peluche" │ │ • Quantité: 42 (pourquoi pas ?) │ │ │ │ form.submit() // Pray it works 🙏 │ └─────────────────────────────┬───────────────────────────────┘ │ ⬇️ Test vérifie la transmission ┌─────────────────────────────▼───────────────────────────────┐ │ ⚙️ COUCHE API (Backend) ✅ API traite │ ├─────────────────────────────────────────────────────────────┤ │ • Endpoint REST /orders │ │ • Validation des données │ │ • Calcul du prix (licornes = €€€) │ │ │ │ POST /api/orders │ │ status: 201 │ └─────────────────────────────┬───────────────────────────────┘ │ ⬇️ Test vérifie la persistance ┌─────────────────────────────▼───────────────────────────────┐ │ 🗄️ COUCHE BASE DE DONNÉES ✅ DB persiste │ ├─────────────────────────────────────────────────────────────┤ │ • Tables: products, orders, customers │ │ • Transaction ACID │ │ • Contraintes respectées │ │ │ │ INSERT INTO orders -- Magic happens here ✨ │ └─────────────────────────────┬───────────────────────────────┘ │ ⬇️ Test vérifie l'appel externe ┌─────────────────────────────▼───────────────────────────────┐ │ 💳 SERVICES EXTERNES ✅ Paiement OK │ ├─────────────────────────────────────────────────────────────┤ │ • Service de paiement Stripe │ │ • Tokenisation carte │ │ • Débit de 1337.42€ │ │ │ │ stripe.charge() // 💸 Bye bye money │ └─────────────────────────────────────────────────────────────┘ ## 🎉 Résultat du Test d'Intégration ✓ Formulaire → API : PASS ✓ API → Base de données : PASS ✓ API → Service paiement : PASS ✓ Cohérence des données : PASS 🤓 "Un test d'intégration, c'est comme un chef d'orchestre : il faut que tous les musiciens jouent la même partition... sinon ça donne du jazz expérimental !" ## 🧪 Tests End-to-End (E2E) : Le Grand Frisson de l'Automatisation > "Si le bouton ne clique pas, le client ne paie pas." Les tests E2E sont là pour simuler un vrai utilisateur. Tu veux tester tout le flow : login, achat, logout ? C'est ici. ### 🛠️ Outils populaires : * Playwright * Cypress * Selenium (😬) ### ✅ Avantages * Simule le parcours utilisateur complet * Détecte les régressions UI ou frontend/backend ### ❌ Inconvénients * Lents. Très lents. * Fragiles. Très fragiles. * Maintenance élevée (un QA engineer peut y passer sa vie) # 🤖 Schéma 2: E2E Testing vs Human Testing > _"Même parcours, même vérifications, mais qui gagne ?"_ ## L'Affrontement Épique ┌─────────────────────────────┐ ⚔️ VS ⚔️ ┌─────────────────────────────┐ │ 👨‍💻 L'HUMAIN TESTEUR │ │ 🤖 LE TEST E2E │ ├─────────────────────────────┤ ├─────────────────────────────┤ │ │ │ │ │ 🧑‍💼 │ │ 🤖 │ │ │ │ │ │ 💭 "Bon, on va tester │ │ 💭 "BEEP BOOP. Exécution │ │ cette app... encore... │ │ du scénario 1337..." │ │ pour la 47ème fois..." │ │ │ │ │ │ │ │ ACTIONS: │ │ CODE: │ │ │ │ │ │ 1. 🖱️ Ouvre le navigateur │ │ cy.visit('localhost:3000') │ │ *soupir* Firefox ou │ │ │ │ Chrome aujourd'hui ? │ │ cy.get('[data-testid=form]')│ │ │ │ .should('be.visible') │ │ 2. ⌨️ Tape l'URL │ │ │ │ localhost:3000... enfin │ │ cy.get('#email') │ │ j'espère que c'est ça │ │ .type('test@example.com') │ │ │ │ │ │ 3. ⏳ Attend le chargement │ │ cy.get('button[type=submit]')│ │ Hmm... c'est long là... │ │ .click() │ │ ça marche ? │ │ │ │ │ │ cy.contains('Success!') │ │ 4. 👀 Regarde l'interface │ │ .should('be.visible') │ │ "Tiens, ce bouton a │ │ │ │ bougé de 2px..." │ │ │ │ │ │ ⚡ Temps d'exécution: 0.3s │ │ 5. 📝 Remplit le formulaire │ │ 🎯 Précision: 100% │ │ Email: test@test.com │ │ 🔄 Répétable: ∞ fois │ │ (encore et toujours) │ │ 📊 Rapports: Automatiques │ │ │ │ │ │ 6. 📤 Clique sur Submit │ │ │ │ *croise les doigts* │ │ 💭 "BEEP BOOP. Test terminé│ │ │ │ Prêt pour les 999 │ │ 7. ✅ Vérifie le résultat │ │ autres scénarios..." │ │ "Success!" - Ouf, ça │ │ │ │ marche... cette fois │ │ │ │ │ │ │ │ 💭 "Bon, maintenant il faut │ │ │ │ que je teste avec un │ │ │ │ autre email... et sur │ │ │ │ mobile... et Safari😵" │ │ │ └─────────────────────────────┘ └─────────────────────────────┘ ## 🏆 Verdict du Match Critère | 👨‍💻 Humain | 🤖 Robot | Gagnant ---|---|---|--- **Vitesse** | 3 minutes | 0.3 secondes | 🤖 >>> 👨‍💻 **Précision** | "Oups, cliqué à côté" | Chirurgicale | 🤖 > 👨‍💻 **Répétabilité** | "Pas un lundi matin..." | 24h/24, 7j/7 | 🤖 >>> 👨‍💻 **Créativité** | "Et si je clique là ?" | Suit le script | 👨‍💻 >>> 🤖 **Détection de bugs bizarres** | "En diagonale ça plante" | Ne sort jamais du script | 👨‍💻 >>> 🤖 ## 🤝 La Vérité > **L'E2E teste comme un humain très discipliné qui n'aurait jamais de lundi matin...** > > **Mais qui ne trouvera jamais le bug bizarre qui arrive seulement "quand on fait ça en diagonale" 🤷‍♂️** ## 🔥 Tests de Charge : T'as Pas Crashé, Donc T'as Gagné > "Tu peux scaler ton app à 1 million d'utilisateurs ? Moi non plus. Mais j'ai un test qui dit que _peut-être_." Tu veux savoir ce que devient ton API sous pression ? Tu fais des **tests de charge**. ### 🛠️ Outil testé: * Gatling ### ✅ Avantages * Identifie les goulets d'étranglement * Fournit des metrics (latence, taux d'erreur, throughput) * Essentiel en préprod sur les services critiques ### ❌ Inconvénients * Difficiles à calibrer et interpréter * Peuvent donner un faux sentiment de sécurité * Nécessitent une vraie stratégie d'analyse ## ⚖️ Résumé Comparatif Type de test | Vitesse 🚀 | Fiabilité 🛡️ | Portée 🎯 | Complexité 🧠 ---|---|---|---|--- Unitaire (mock) | Ultra rapide | Moyenne | Petite | Moyenne Unitaire (classic) | Rapide | Bonne | Moyenne | Basse à moyenne Intégration | Moyenne | Moyenne | Moyenne à large | Moyenne à haute End-to-End (E2E) | Lente | Moyenne | Large | Haute Charge | Variable | Bonne (si bien fait) | Large | Haute ## 👋 Conclusion : Teste intelligemment, pas aveuglément Les tests ne sont pas là pour faire joli sur un dashboard. Ils sont là pour **te sauver le c*l à 2h du matin** quand la prod tombe. ✅ Reste pragmatique ✅ N'overengineere pas tes tests ✅ Utilise le bon test pour le bon usage Et surtout : **Si tu commites sans tests, assume quand tout pète. 😈** 📌 Tu veux plus d'articles techniques ? Suis-moi ici sur dev.to, ou viens troller (gentiment) en commentaires. **#DevOps #TDD #Testing #SoftwareCraftsmanship #TestezVosProds**
0 0 0 0
DEV Community
DEV Community
@dev.to.web.brid.gy
10 months ago
Preview
Mock Me If You Can : Guide de Survie des Tests Logiciels # 🧪 Mock Me If You Can : Guide de Survie des Tests Logiciels Ah, les tests. Ce mot magique qui peut transformer un commit innocent en un feu d'artifice rouge dans ton pipeline CI. Tu pensais avoir tout compris ? Détrompe-toi, camarade développeur chevronné. Voici un tour d'horizon **(un peu) technique** , **(légèrement) sarcastique** et **(probablement) pertinent** des principaux types de tests logiciels : * ✅ Tests unitaires (_mockistes_ vs _classicists_) * 🔌 Tests d'intégration * 🧪 Tests end-to-end (E2E) * 🔥 Tests de charge _La fameuse pyramide des tests : moins tu montes, mieux tu dors._ ## 🎬 Bonus : Notre Talk "La Légende des Gardiens du Code" > 🗣️ **Tu préfères regarder plutôt que lire ?** On t'a couvert ! Le **06 juin 2024** , avec mon acolyte **Jeremy Bernard** , on a donné un talk au **DevQuest** sur ce sujet brûlant : les types de tests et la CI/CD qui va avec. ### 🎥 Le Talk en Vidéo 📺 **Regarder "La Légende des Gardiens du Code" sur YouTube** _(Lien disponible prochainement !)_ ### 📊 Les Slides de la Conférence 💾 **Télécharger le PowerPoint de la conférence** _Spoiler alert : On y raconte comment les tests sont les vrais gardiens de votre code... et pourquoi sans eux, c'est l'anarchie totale en production ! 🔥_ ## 🧩 Tests Unitaires : Mockistes vs Classicists — Le Match de Boxe > "Un bon test unitaire isole. Un test unitaire parfait n'existe pas." > > — Un développeur qui a perdu 3 jours à débugger un mock ### 🥊 Camp 1 : Les Mockistes (a.k.a. London School) Tu veux tout contrôler ? Tu adores faire semblant ? Bienvenue chez les **mockistes**. Ici, chaque dépendance est simulée. Tu ne veux pas tester si `fetchData()` accède à une vraie BDD, tu veux juste qu'il _croie_ qu'elle existe. #### ✅ Avantages * Hyper rapide * Super précis : tu sais exactement ce qui est cassé * Isolation complète du code testé #### ❌ Inconvénients * Fragile comme un test PCR dans une boîte chaude * Teste souvent l'implémentation plus que le comportement * Maintenance élevée des mocks ### 🧘‍♂️ Camp 2 : Les Classicists (a.k.a. Chicago School) Tu préfères tester sans te casser la tête à tout mocker ? Tu es **classicist**. Tu laisses les vraies dépendances s'exécuter dans leur contexte logique. #### ✅ Avantages * Teste des comportements réels * Moins de maintenance liée aux mocks #### ❌ Inconvénients * Moins rapide * Plus sujet aux tests flakies * Risque de mauvaise séparation des responsabilités ### 🤯 Le Vrai Dilemme ? * Les **mockistes** valident les _interactions_ * Les **classicists** valident les _résultats_ 👉 **Choisis ton camp, mais reste cohérent.** ## 🔌 Tests d'Intégration : Là où les Bugs naissent > "Ça marche en local, mais en prod c'est l'apocalypse ? Tu fais pas de tests d'intégration, hein ?" Le test d'intégration, c'est le café serré du TDD. Il ne teste pas chaque grain, mais la machine complète. ### ✅ Avantages * Révèle les vrais bugs (ceux qui pètent en prod) * Valide les comportements transverses : transactions, configs, etc. ### ❌ Inconvénients * Lents, très lents * Fragiles si dépendances instables * Requiert souvent un environnement spécifique ou des outils comme **Testcontainers** , **WireMock** , etc. # 🔧 Schéma 1: Test d'Intégration Multi-Couches > _"Quand toutes les couches doivent jouer ensemble... sans se disputer"_ > ┌─────────────────────────────────────────────────────────────┐ │ 🖥️ COUCHE UI (Frontend) ✅ UI répond │ ├─────────────────────────────────────────────────────────────┤ │ • Formulaire de commande │ │ • Saisie produit: "Licorne en peluche" │ │ • Quantité: 42 (pourquoi pas ?) │ │ │ │ form.submit() // Pray it works 🙏 │ └─────────────────────────────┬───────────────────────────────┘ │ ⬇️ Test vérifie la transmission ┌─────────────────────────────▼───────────────────────────────┐ │ ⚙️ COUCHE API (Backend) ✅ API traite │ ├─────────────────────────────────────────────────────────────┤ │ • Endpoint REST /orders │ │ • Validation des données │ │ • Calcul du prix (licornes = €€€) │ │ │ │ POST /api/orders │ │ status: 201 │ └─────────────────────────────┬───────────────────────────────┘ │ ⬇️ Test vérifie la persistance ┌─────────────────────────────▼───────────────────────────────┐ │ 🗄️ COUCHE BASE DE DONNÉES ✅ DB persiste │ ├─────────────────────────────────────────────────────────────┤ │ • Tables: products, orders, customers │ │ • Transaction ACID │ │ • Contraintes respectées │ │ │ │ INSERT INTO orders -- Magic happens here ✨ │ └─────────────────────────────┬───────────────────────────────┘ │ ⬇️ Test vérifie l'appel externe ┌─────────────────────────────▼───────────────────────────────┐ │ 💳 SERVICES EXTERNES ✅ Paiement OK │ ├─────────────────────────────────────────────────────────────┤ │ • Service de paiement Stripe │ │ • Tokenisation carte │ │ • Débit de 1337.42€ │ │ │ │ stripe.charge() // 💸 Bye bye money │ └─────────────────────────────────────────────────────────────┘ ## 🎉 Résultat du Test d'Intégration ✓ Formulaire → API : PASS ✓ API → Base de données : PASS ✓ API → Service paiement : PASS ✓ Cohérence des données : PASS 🤓 "Un test d'intégration, c'est comme un chef d'orchestre : il faut que tous les musiciens jouent la même partition... sinon ça donne du jazz expérimental !" ## 🧪 Tests End-to-End (E2E) : Le Grand Frisson de l'Automatisation > "Si le bouton ne clique pas, le client ne paie pas." Les tests E2E sont là pour simuler un vrai utilisateur. Tu veux tester tout le flow : login, achat, logout ? C'est ici. ### 🛠️ Outils populaires : * Playwright * Cypress * Selenium (😬) ### ✅ Avantages * Simule le parcours utilisateur complet * Détecte les régressions UI ou frontend/backend ### ❌ Inconvénients * Lents. Très lents. * Fragiles. Très fragiles. * Maintenance élevée (un QA engineer peut y passer sa vie) # 🤖 Schéma 2: E2E Testing vs Human Testing > _"Même parcours, même vérifications, mais qui gagne ?"_ ## L'Affrontement Épique ┌─────────────────────────────┐ ⚔️ VS ⚔️ ┌─────────────────────────────┐ │ 👨‍💻 L'HUMAIN TESTEUR │ │ 🤖 LE TEST E2E │ ├─────────────────────────────┤ ├─────────────────────────────┤ │ │ │ │ │ 🧑‍💼 │ │ 🤖 │ │ │ │ │ │ 💭 "Bon, on va tester │ │ 💭 "BEEP BOOP. Exécution │ │ cette app... encore... │ │ du scénario 1337..." │ │ pour la 47ème fois..." │ │ │ │ │ │ │ │ ACTIONS: │ │ CODE: │ │ │ │ │ │ 1. 🖱️ Ouvre le navigateur │ │ cy.visit('localhost:3000') │ │ *soupir* Firefox ou │ │ │ │ Chrome aujourd'hui ? │ │ cy.get('[data-testid=form]')│ │ │ │ .should('be.visible') │ │ 2. ⌨️ Tape l'URL │ │ │ │ localhost:3000... enfin │ │ cy.get('#email') │ │ j'espère que c'est ça │ │ .type('test@example.com') │ │ │ │ │ │ 3. ⏳ Attend le chargement │ │ cy.get('button[type=submit]')│ │ Hmm... c'est long là... │ │ .click() │ │ ça marche ? │ │ │ │ │ │ cy.contains('Success!') │ │ 4. 👀 Regarde l'interface │ │ .should('be.visible') │ │ "Tiens, ce bouton a │ │ │ │ bougé de 2px..." │ │ │ │ │ │ ⚡ Temps d'exécution: 0.3s │ │ 5. 📝 Remplit le formulaire │ │ 🎯 Précision: 100% │ │ Email: test@test.com │ │ 🔄 Répétable: ∞ fois │ │ (encore et toujours) │ │ 📊 Rapports: Automatiques │ │ │ │ │ │ 6. 📤 Clique sur Submit │ │ │ │ *croise les doigts* │ │ 💭 "BEEP BOOP. Test terminé│ │ │ │ Prêt pour les 999 │ │ 7. ✅ Vérifie le résultat │ │ autres scénarios..." │ │ "Success!" - Ouf, ça │ │ │ │ marche... cette fois │ │ │ │ │ │ │ │ 💭 "Bon, maintenant il faut │ │ │ │ que je teste avec un │ │ │ │ autre email... et sur │ │ │ │ mobile... et Safari😵" │ │ │ └─────────────────────────────┘ └─────────────────────────────┘ ## 🏆 Verdict du Match Critère | 👨‍💻 Humain | 🤖 Robot | Gagnant ---|---|---|--- **Vitesse** | 3 minutes | 0.3 secondes | 🤖 >>> 👨‍💻 **Précision** | "Oups, cliqué à côté" | Chirurgicale | 🤖 > 👨‍💻 **Répétabilité** | "Pas un lundi matin..." | 24h/24, 7j/7 | 🤖 >>> 👨‍💻 **Créativité** | "Et si je clique là ?" | Suit le script | 👨‍💻 >>> 🤖 **Détection de bugs bizarres** | "En diagonale ça plante" | Ne sort jamais du script | 👨‍💻 >>> 🤖 ## 🤝 La Vérité > **L'E2E teste comme un humain très discipliné qui n'aurait jamais de lundi matin...** > > **Mais qui ne trouvera jamais le bug bizarre qui arrive seulement "quand on fait ça en diagonale" 🤷‍♂️** ## 🔥 Tests de Charge : T'as Pas Crashé, Donc T'as Gagné > "Tu peux scaler ton app à 1 million d'utilisateurs ? Moi non plus. Mais j'ai un test qui dit que _peut-être_." Tu veux savoir ce que devient ton API sous pression ? Tu fais des **tests de charge**. ### 🛠️ Outil testé: * Gatling ### ✅ Avantages * Identifie les goulets d'étranglement * Fournit des metrics (latence, taux d'erreur, throughput) * Essentiel en préprod sur les services critiques ### ❌ Inconvénients * Difficiles à calibrer et interpréter * Peuvent donner un faux sentiment de sécurité * Nécessitent une vraie stratégie d'analyse ## ⚖️ Résumé Comparatif Type de test | Vitesse 🚀 | Fiabilité 🛡️ | Portée 🎯 | Complexité 🧠 ---|---|---|---|--- Unitaire (mock) | Ultra rapide | Moyenne | Petite | Moyenne Unitaire (classic) | Rapide | Bonne | Moyenne | Basse à moyenne Intégration | Moyenne | Moyenne | Moyenne à large | Moyenne à haute End-to-End (E2E) | Lente | Moyenne | Large | Haute Charge | Variable | Bonne (si bien fait) | Large | Haute ## 👋 Conclusion : Teste intelligemment, pas aveuglément Les tests ne sont pas là pour faire joli sur un dashboard. Ils sont là pour **te sauver le c*l à 2h du matin** quand la prod tombe. ✅ Reste pragmatique ✅ N'overengineere pas tes tests ✅ Utilise le bon test pour le bon usage Et surtout : **Si tu commites sans tests, assume quand tout pète. 😈** 📌 Tu veux plus d'articles techniques ? Suis-moi ici sur dev.to, ou viens troller (gentiment) en commentaires. **#DevOps #TDD #Testing #SoftwareCraftsmanship #TestezVosProds**
0 0 0 0
Nebraska.Code
Nebraska.Code
@nebraskacode.bsky.social
10 months ago
Post image

Brian Zimmer is 'Roadmapping with Critical Thought' July 25th at Nebraska.Code().

nebraskacode.amegala.com

#Roadmapping #TechConf #SoftwareCraftsmanship #Nebraska #DontPanicLabs #Technology #TechCommunity #HeartlandDev #DeveloperConference #Programming #Nebraska #criticalthinking

2 1 0 0