En TDD, l’étape la plus sous-estimée est le refactoring. Finalement, il n’y aurait pas qu’un seul cycle TDD, mais un double cycle, un cycle principal et un cycle d’amélioration, ce dernier étant la 3ème étape du cycle principal
Lire la suiteTDD
Il y a quelques années, j’avais déjà 20 ans d’expérience en développement, et j’avais vu énormément de sujets. Je savais bien qu’il y avait aussi de très nombreux sujets sur lesquels je ne connaissais rien, et j’en avais de plus en plus conscience. Mais quelque chose de plus me trottait dans la tête : et si j’avais aussi besoin de réviser les bases ? Est-ce que j'avais besoin de revoir les choses que je connaissais déjà ?
Lire la suiteIntroduction 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 suiteIntroduction 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 suiteIntroduction 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
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 suiteIntroduction 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 suiteIntroduction 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
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 suiteIntroduction 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
