Publications de Mickael Wegerich

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
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
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
Archi & techno

Projet IT : S’adapter à un monde qui change – Gestion des sources de données

Voilà plusieurs années que je travaille dans le monde des projets informatiques, tout d’abord dans le rôle du client (MOA et Product Owner) et maintenant en tant que membre de l’équipe de développement. J’ai pu constater que plusieurs points de souffrance apparaissent très (trop) régulièrement mais depuis quelques temps déjà, j’arrive à les devancer. Nous allons voir comment. Disclaimer L’article fait partie de la série Projet IT : S’adapter à un monde qui change. Dans chacun de ces articles, je vous propose des retours d’expériences…

Lire la suite
Archi & techno

Projet IT : S’adapter à un monde qui change – Gestion des mises-à-jour des frameworks

Voilà plusieurs années que je travaille dans le monde des projets informatiques, tout d’abord dans le rôle du client (MOA et Product Owner) et maintenant en tant que membre de l’équipe de développement. J’ai pu constater que plusieurs points de souffrance apparaissent très (trop) régulièrement mais depuis quelques temps déjà, j’arrive à les devancer. Nous allons voir comment. Disclaimer L’article fait partie de la série Projet IT : S’adapter à un monde qui change. Dans chacun de ces articles, je vous propose des retours d’expériences…

Lire la suite
Archi & techno

Projet IT : S’adapter à un monde qui change – Gestion des dépendances extérieures

Voilà plusieurs années que je travaille dans le monde des projets informatiques, tout d’abord dans le rôle du client (MOA et Product Owner) et maintenant en tant que membre de l’équipe de développement. J’ai pu constater que plusieurs points de souffrance apparaissent très (trop) régulièrement mais depuis quelques temps déjà, j’arrive à les devancer. Nous allons voir comment. Disclaimer L’article fait partie de la série Projet IT : S’adapter à un monde qui change. Dans chacun de ces articles, je vous propose des retours d’expériences…

Lire la suite