person-666134_960_720

Les qualités d’un bon test unitaire

Nous présentons ici quelques caractéristiques que tout bon test unitaire se devrait de présenter. Dans la pratique, et selon le contexte, il est difficile de cumuler toutes ces qualités. Il s’agit avant tout d’indications qu’il est important de garder à l’esprit quand on écrit un test unitaire. Ciblé En ciblant ce qui est testé, on s’astreint[…]

maxresdefault

Des anti-patterns pour les fêtes

En fin d’année les bêtisiers étant généralement à l’honneur, c’est l’occasion de présenter des exemples de choses à ne pas faire ou à éviter dans le développement d’un projet. Le God Object Le god object est une forme de programmation particulière s’appuyant sur le principe « Dieu est omniscient et omnipotent ». En pratique, on se retrouve avec une seule[…]

Ghostbusters-team

La propreté du code, une responsabilité collective

La dégradation du code Lorsqu’on travaille seul (ou tout au plus en binôme) sur un projet, il est beaucoup plus facile d’appliquer les règles du clean code. D’autant plus si il s’agit d’un nouveau projet, dont le point de départ est, par définition, propre. Etant seul à faire évoluer le code, on est seul responsable de sa propreté,[…]

Legoclean2

Clean Code : partie 2 – le nommage

N’importe quel développeur peut produire du code qu’un ordinateur est capable de comprendre. Ce qui caractérise un bon développeur, c’est qu’il écrit du code que d’autres développeurs sont capables de comprendre. Dans cette optique, un nommage rigoureux des éléments du code est essentiel. Limiter les commentaires En matière de nommage des identificateurs, la règle d’or suivante devrait[…]

glass-271151_960_720

Test Driven Development : les bases

En test-driven development (TDD), on cherche à écrire du code directement testable; cela entraîne des conséquences immédiates sur la conception. Le processus se présente ainsi : on part d’une première fonctionnalité, assez simple, en se basant sur sa spécification; on écrit le code testant cette fonctionnalité et on l’exécute immédiatement : la fonctionnalité n’étant pas implémentée,[…]

bowling-balls-658385_640

TDD : Bowling Game Kata

Le kata de code Bowling Game tel qu’il est présenté ici par Uncle Bob est une parfaite illustration des concepts du Test-Driven Development, notamment de la boucle red-green-refactor, et de la notion de baby steps. Prenez d’abord connaissance du problème (première slide) et essayez de proposer une solution, en essayant d’utiliser l’approche TDD ou non (à[…]

gherkin-861550_640

BDD avec Cucumber

Cucumber est un framework de test dédié à l’écriture de tests fonctionnels dans un style behaviour-driven development (BDD). La description des tests s’effectue au moyen de Gherkin, un langage non-technique et orienté langage naturel afin de s’adresser à toute l’équipe de développement, y compris les analystes métiers. Gherkin supporte une cinquantaine de langues (les mots-clés ont été traduits)[…]

abstract-1097763_640

Stratégies de test

Tests façon BDD Dans le cadre de behaviour-driven development (BDD), le terme « spécifications » va être préférable au terme « tests ». L’idée est de rapprocher l’élaboration des tests unitaires de l’élaboration des tests fonctionnels, et d’impliquer fortement les experts du métier dans l’écriture des tests. L’élaboration des scénarios de test repose grandement sur le canevas Given-When-Then : (Given) (Etant[…]

businessmen-948021_960_720

DevOps

DevOps est un mouvement cherchant à rassembler les équipes intervenant dans le système d’information, réunissant en une même équipe les Dev en charge des évolutions et les Ops en charge de l’exploitation. L’objectif est ainsi de favoriser le travailler ensemble entre les équipes de développement et les équipes de production, produisant ainsi plus de valeur pour[…]

geometry-1023843_960_720

Continuous deployment : quelques patterns

Feature Flipping Le code en cours de développement est livré en production, mais son exécution est conditionnée à la présence d’un flag qui peut être activé ou non par configuration, sans nécessiter un redéploiement. Ce mécanisme peut se mettre en oeuvre de façon simple dans le code, avec un helper chargé de vérifier l’activation de la fonctionnalité[…]

railway-tracks-562941_960_720

Gestion de configuration : les stratégies

Mono-branche Une seule branche qui est la branche principale Tous les projets commencent par ça L’intégration continue doit forcer les développeurs à committer du code stable Fonctionne en petite équipe mais nécessite beaucoup de communication et une intégration continue performante Une branche par équipe En plus de la branche principale, chaque équipe dispose de sa[…]

fractal-1076854_960_720

Intégration continue : en pratique

Les pré-requis Les trois éléments suivants sont indispensables : un référentiel de contrôle de version, dans lequel tous les éléments du projet sont publiés un build automatisé le plus important : l’adhésion complète de l’équipe  Contrôle de version Le référentiel de contrôle de version est indispensable, quel que soit le nombre de développeurs impliqués dans[…]

continuous

Intégration continue : généralités

Définition de l’intégration continue (CI) par Martin Fowler, précurseur et promoteur de cette pratique : « Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to[…]

street-lights-600472_960_720

Gestion de configuration : généralités

La gestion de configuration (ou gestion de versions), par l’utilisation du source-control management (SCM) est une pierre angulaire du Continuous Delivery, c’est le référentiel à partir duquel il est possible de construire les livrables de façon reproductible et automatisée. Le SCM est également au centre du travail en équipe et nécessite, pour être efficace, la[…]

complex-664440_960_720

Continuous Delivery : généralités

Problématique de la livraison de logiciel : c’est traditionnellement un événement qui mobilise beaucoup de ressources à une date prédéfinie à l’avance, qui est synonyme de stress pour les équipes, sur lequel certains intervenants ont le sentiment de jouer leur carrière, et qui se déroule rarement comme prévu. Il est également courant de provoquer une[…]