Software Craftsmanship

Software Craftsmanship

Un test peut en cacher un autre – Tests unitaires – P2

Introduction L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. A travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Deux phrases extraites de l’article de Ian Cooper ont été mises en avant : “Le code issu d’un refactoring ne requiert pas de nouveaux tests” “Je vous recommande d’utiliser ports/adaptateurs et d’écrire les tests en outside-in depuis le use case” Ces deux axes…

Lire la suite
Software Craftsmanship

Test-driven development sur votre infrastructure avec ansible – Compte-rendu du talk de Sebastián Caceres et Tanguy Patte à La Duck Conf 2020

TDD ANSIBLE

Dans ce talk, Sebastián et Tanguy nous expliquent comment faire du TDD sur du code d'infrastructure avec ansible. L’infrastructure as Code devenant la norme pour la création d’infrastructure, nous souhaiterions profiter des bonnes pratiques du Software Craftsmanship pour garantir un code d’infrastructure de qualité. TDD Une des pratiques associée au Software Craftsmanship est le TDD ou Test Driven Development. Pour rappel cette pratique consiste à :  Ecrire un test. Vérifier qu’il échoue. Ecrire le code pour faire passer ce test. Vérifier qu’il passe. Remanier le code…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests unitaires – P1

Introduction L’article d’introduction débute en listant certaines différences entre ma vision en terme d’architecture applicative ou encore de rédaction des tests, que je peux avoir avec d’autres développeurs. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Deux phrases extraites de l’article de Ian Cooper ont été mises en avant : “Le code issu d’un refactoring ne requiert pas de nouveaux tests” “Je vous recommande d’utiliser ports/adaptateurs et d’écrire les tests en outside-in depuis le use case” Ces…

Lire la suite
Software Craftsmanship

Accélérer le développement : une histoire de plomberie

Moi: Après avoir passé 5 jours dans l'équipe de développement, je pense qu'il serait judicieux de former et accompagner les développeurs à la mise en place de [la pratique X]. (remplacer [la pratique X] par : Test-Driven Development (TDD), Pair/Mob programming, Tres Amigos, ...)  Le DSI: [La pratique X] ?  Moi: Oui, [la pratique X], tu sais celle qui consiste à faire gnagnagni et gnagnagna.  Le DSI: Cela me semble très coûteux, et… on a vraiment pas le temps ! Moi: Pourtant, au vu de…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Un peu de théorie

Introduction En discutant avec des développeurs, je remarque plusieurs choses : Nos approches sur l’architecture applicative du code sont différentes Les définitions que nous donnons aux catégories de tests sont différentes Les façons de rédiger les tests sont différentes Sans généraliser, je pense qu'il est parfois difficile dans ce contexte d'identifier précisément quoi tester et comment. Être au clair sur ces trois points me semble important et permet de me faciliter la vie et d'être plus confiant au quotidien, laissant beaucoup moins de place à…

Lire la suite
Software Craftsmanship

Meriem Berkane, CTO : “Le Tech Lead est l’incarnation de nos valeurs et le garant de la vision technique d’OCTO.”

Chez OCTO depuis plus de 10 ans , Meriem fait partie des personnes fondatrices de l’entreprise. Ancienne leadeuse de la tribu Nouvelles Architectures de Données, elle est désormais CTO et participe à la définition de la vision stratégique et technique d’OCTO. Qui de mieux pour nous parler du “tech leading à la OCTO” ?

Lire la suite
Software Craftsmanship

Interview Céline Gilet – « Le Tech Lead n’est pas un super héros ! »

Depuis plus de 4 ans chez OCTO, Céline, membre de la tribu CRAFT, est devenue une référence parmi nos Tech Lead. Découvrez sa vision de ce rôle à part. Pour toi, quel est le rôle du Tech Lead ?  Pour moi, c’est faire en sorte que l’équipe au sens large (Développeurs, Ops, Fonctionnels, Product Owner) arrive à délivrer régulièrement de la valeur. Concrètement, il s’agit de jongler et prioriser en permanence entre plusieurs casquettes : expertise, accompagnement, coaching et formation.

Lire la suite
Software Craftsmanship

La fin de la « dette technique » : du passé ne pas faire table rase

Dans les articles qui précèdent, j'ai exprimé l'idée de remplacer, dans le modèle que nous utilisons lorsque nous parlons de "gérer la dette technique" d'une solution logicielle, le diagnostic : Notre solution est endettée techniquement par l'hypothèse : Notre solution repose sur des procédés en conflit Cette hypothèse permet de répondre plus efficacement au problème de la "dette technique" en ce qu'elle substitue à une métaphore inopérante des outils permettant d'appréhender plus précisément et plus efficacement le problème en question. Le propos n'est pas de…

Lire la suite
Software Craftsmanship

La fin de la « dette technique » : résoudre les conflits

Dans les articles précédents, j'ai essayé d'établir sur la base d'exemples (simples) cette observation : Lorsque nous considérons une solution logicielle existante, nous parlons souvent de la "dette technique" qui caractérise cette solution. Par ce terme, nous voulons pointer un certains nombre de défauts de qualité (de maintenabilité, etc.), qui sont comme autant de manquements à un état de l'art communément admis, lequel reste en fait indéfini et hypothétique. Le terme de “dette technique”, popularisé par Ward Cunningham, désignait initialement un procédé particulier de conception…

Lire la suite
Software Craftsmanship

Vos tests d’infrastructure de bout-en-bout avec Kitchen

Au cours de précédents articles, nous vous avons introduit le Test Driven Development sur du code d’infrastructure avec des outils tels que Molecule ou Terratest. Dans cet article, nous vous présenterons Kitchen-CI, un outil qui permet, avec l’aide de bibliothèques de test comme InSpec ou ServerSpec, de tester les différentes briques de son infrastructure. Kitchen Kitchen-CI (de son vrai nom) est un outil écrit en Ruby par les développeurs de Chef. À l’aide de plugins spécifiques, il permet d’effectuer des tests pour vérifier la conformité…

Lire la suite