TDD

Software Craftsmanship

Un test peut en cacher un autre – Tests bout en bout et autres

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. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Nous avons pu voir dans les autres articles de la série différents types de tests. Certains nous aidant à vérifier les règles métier comme les tests unitaires : Un test peut en cacher un autre - tests unitaires - partie 1 Un test…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests d’acceptation

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. À 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 avaient retenu l’attention : “Le code issu d’un refactoring ne requiert pas de faire de nouveaux tests dessus !” “Je vous recommande d’utiliser ports/adaptateurs et d’écrire les tests en outside-in depuis le use case.” Nous…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests d’intégration – P1

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. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Nous avons pu voir dans ces articles autour des tests unitaires :  Un test peut en cacher un autre — Tests unitaires — P1 Un test peut en cacher un autre — Tests unitaires — P2 Que ces tests sont exclusivement centrés sur…

Lire la suite
Bonne pratique

Property-based testing : Un contrat d’interface en béton

La compréhension de cet article est facilitée par des connaissances sur l'architecture hexagonale (Clean Archi) et le Domain-Driven Design. Lorsque vous développez un produit en vous basant sur les principes du Domain-Driven Design (DDD) et que vous vous efforcez de respecter les principes de Clean Archi, vous vous retrouvez alors probablement avec une catégorie particulière d'interfaces appelées Repository. Nous allons voir ici qu'une stratégie de test des implémentations se reposant uniquement sur les méthodes de l'interface peut s'avérer très utile pour itérer sur notre implémentation sans influencer notre code métier. Nous allons…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests d’intégration – 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. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Nous avons pu voir dans ces articles autour des tests unitaires :  Un test peut en cacher un autre — Tests unitaires — P1 Un test peut en cacher un autre — Tests unitaires — P2 Que ces tests sont exclusivement centrés sur…

Lire la suite
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. À 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
devops

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

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

Sortir de la consanguinité logicielle

Depuis plusieurs années que je suis consultant chez OCTO, j’ai eu plusieurs fois l’occasion d’auditer le fonctionnement d’équipes de développement, que ce soit pour des audits internes ou des due diligences techniques. Dans ce contexte,  j'ai pu constater un comportement récurrent dans de nombreuses entreprises, notamment chez les startups numériques.

Lire la suite