Hard Delete vs Soft Delete : que choisir ?

Dans l'article précédent nous avons initialisé notre monorepo, la CI, le framework de test et préparé la structure de notre projet et plus précisément de notre Architecture Hexagonale pour la lib core.

Dans ce nouvel article de la série notre objectif va être de mettre en place l'Architecture Hexagonale et de montrer comment grâce à elle nous allons pouvoir développer et créer de la logique métier sans UI (donc sans ouvrir le navigateur ou l'app mobile). Pour cela nous allons travailler en TDD (Test-Driven Development, vous pouvez voir mon article à ce sujet) et utiliser le feedback des tests.

‍

L'Architecture Hexagonale

‍

La structure cible

Pour rappel, voici la structure que l'on va mettre en place à l'issue de cet article :

- src
    - wallet
       - __ tests __
‍         - wallet.service.test.ts
       - domain
‍         - wallet.ts
‍         - wallet.repository.ts
‍         - wallet.service.ts
       - infrastructure
         - in-memory-wallet.repository.ts
         - local-storage-wallet.repository.ts
         - mmkv-wallet.repository.ts
       - user-interface
‍         - wallet.store.ts

‍

Chose promise, chose due ! Nous allons maintenant rentrer dans le détail de chaque fichier, à quoi ils servent et ce qu'ils contient.

‍

Développer en TDD

‍

Lorsqu'on travaille en TDD on commence par le test et ce test va nous guider vers un objectif. Il va nous assurer qu'on suit le bon chemin à l'aide de la boucle de feedback régulière qu'on obtient à l'aide des tests. Pour en savoir plus sur la méthodologie à suivre pour faire du TDD je vous invite à nouveau à lire mon article à ce sujet.

Nous allons commencer par travailler sur l'entité Wallet qui correspond à un portefeuille qui a un solde négatif ou positif (par exemple on peut avoir le portefeuille "Compte Principal Julien" qui a un solde positif de 1000€).

Voici les tests mis en place pour cette entité :

‍

describe('Wallet Service', () => {
	let service: WalletService

	beforeEach(() => {
		const repository = new InMemoryWalletRepository()
		service = new WalletService(repository)
	})

	test('getAll > should retrieve all wallets', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallets = await service.getAll()

		expect(retrievedWallets).toEqual([newWallet])
	})

	test('get > should retrieve a wallet according to an id', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)

		expect(retrievedWallet).toEqual(newWallet)
	})

	test('create > shoudl create a wallet', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		const createdWallet = await service.create(newWallet)
		const retrievedWallets = await service.getAll()
		const retrievedWallet = await service.get(createdWallet.id)

		expect(createdWallet).toEqual(newWallet)
		expect(retrievedWallets).toEqual([newWallet])
		expect(retrievedWallet).toEqual(newWallet)
	})

	test('update > should update the specified wallet', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }
		const updatedWallet = { id: '1', name: 'Wallet 1', balance: 100 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)
		const modifiedWallet = await service.update(updatedWallet)
		const retrievedModifiedWallet = await service.get(modifiedWallet.id)

		expect(retrievedWallet).toEqual(newWallet)
		expect(modifiedWallet).toEqual(updatedWallet)
		expect(retrievedModifiedWallet).toEqual(updatedWallet)
	})

	test('delete > should delete a wallet according to an id', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)
		await service.delete(newWallet.id)
		const retrievedWallets = await service.getAll()

		expect(retrievedWallet).toEqual(newWallet)
		expect(retrievedWallets).toEqual([])
	})
})

‍

‍

On peut comprendre via ces tests que les cas d'utilisations de notre entité sont :

• getAll, récupération de tous les portefeuilles
• get, récupération d'un portefeuille en particulier
• create, création d'un portefeuille
• update, mise à jour d'un portefeuille
• delete, suppression d'un portefeuille

Nous allons voir maintenant comme réussir à mettre en place ces tests.

‍

Domain

‍

Nous allons commencé par créer le contenu de la partie Domain. Dans cette partie nous allons retrouver tout ce qui représente le problème à résoudre (problème métier). C'est une partie qui doit être totalement indépendante.

‍

L'entité

‍

Commençons par créer notre entité Wallet correspondant à un portefeuille.

‍

type Wallet = {
	// un identifiant unique (ex: 4d0c2e72-be1a-4e2c-a189-2f321fcdc3a4)
	id: string

	// un nom (ex: Compte Principal Julien)
	name: string

	// un nombre positif ou négatif pour le solde (ex: +1000€)
	balance: number
}

‍


Le repository

‍

Maintenant que notre entité est définie, nous allons définir une interface que l'on appelle également port qui va préciser comment interagir avec cette entité. Nous utilisons ici un modèle de conception d'inversion de dépendances qui nous permet de rester totalement libre sur les outils à utiliser pour respecter cette interface. Nous pourrons très bien implémenté cette interface en utilisant une base de données, une API ou un localStorage par exemple, le domaine s'en fiche.

‍

interface WalletRepository {
	getAll(): Promise<Wallet[]>
	get(walletId: string): Promise<Wallet | undefined>
	create(wallet: Wallet): Promise<Wallet>
	update(wallet: Wallet): Promise<Wallet>
	delete(walletId: string): Promise<void>
}

‍

Le service

‍

Nous avons notre entité et nous savons commencer interagir avec, maintenant nous allons créer un service qui va consumer une implémentation du de notre interface repository (partie suivante dans l'infrastructure).

‍

class WalletService implements WalletRepository {
	constructor(private repository: WalletRepository) {}

	getAll() {
		return this.repository.getAll()
	}

	get(walletId: string) {
		return this.repository.get(walletId)
	}

	create(wallet: Wallet) {
		return this.repository.create(wallet)
	}

	update(wallet: Wallet) {
		return this.repository.update(wallet)
	}

	delete(walletId: string) {
		return this.repository.delete(walletId)
	}
}

‍

Infrastructure

L'infrastructure est composée des différentes implémentations des ports du domaine, on les appelle également Adapters. Ici, nous aurons du code spécifique pour consommer une technologie concrète (une base de données, une API, etc.). C'est une partie qui ne doit dépendre uniquement du domaine.

‍

L'implémentation du repository

Nous allons maintenant voir l'une des implémentation possible de notre WalletRepository. Pour commencer nous allons faire du in-memory, pratique notamment pour la mise en place des premiers tests de nos cas d'utilisations.

‍

class InMemoryWalletRepository implements WalletRepository {
	private wallets: Wallet[] = []

	getAll() {
		return Promise.resolve(this.wallets)
	}

	get(walletId: string) {
		return Promise.resolve(this.wallets.find((wallet) => wallet.id === walletId))
	}

	create(wallet: Wallet) {
		this.wallets.push(wallet)
		return Promise.resolve(wallet)
	}

	update(wallet: Wallet) {
		const index = this.wallets.findIndex((w) => w.id === wallet.id)
		this.wallets[index] = wallet
		return Promise.resolve(wallet)
	}

	delete(walletId: string) {
		const index = this.wallets.findIndex((w) => w.id === walletId)
		this.wallets.splice(index, 1)
		return Promise.resolve()
	}
}

‍

Comment dis précédemment, il s'agit d'une des multiples implémentation possible de notre WalletRepository. Nous pouvons très bien imaginer plus tard mettre en place un LocalStorageWalletRepository ou bien un SupabaseWalletRepostory.

Vous pouvez consulter mon répertoire public de broney sur GitHub pour voir mon implémentation de ces 2 repository et notamment de comment j'ai adapté ma série de test pour garantir leur bon fonctionnement.

‍

‍

User Interface

‍

La partie user interface est composée de tous les adaptateurs qui constituent les points d'entrée de l'application. Les utilisateurs utilisent ces adaptateurs pour pouvoir interagir avec le coeur de l'application. Dans notre cas nous allons régulièrement utiliser des stores en utilisant la libraire Zustand. Il s'agit d'une libraire JS minimaliste pour la gestion d'états (une solution plus complexe serait par exemple Redux).

‍

Voyons voir comment articuler notre store Zustand pour permettre à l'utilisateur d'interagir avec le coeur de l'application.

‍

import { createStore } from 'zustand/vanilla'
import { InMemoryWalletRepository } from '../infrastructure/in-memory-wallet.repository'
import { WalletService } from '../domain/wallet.service'
import { Wallet } from '../domain/wallet'

const repository = new InMemoryWalletRepository()
const service = new WalletService(repository)

type States = {
	wallets: Wallet[]
	currentWallet: Wallet | undefined
}

type Actions = {
	load: () => void
	setCurrentWallet: (wallet: Wallet) => void
	getWallet: (walletId: string) => void
	createWallet: (wallet: Wallet) => void
	updateWallet: (wallet: Wallet) => void
	deleteWallet: (walletId: string) => void
}

export const walletStore = createStore<States & Actions>()((set) => ({
	wallets: [],
	currentWallet: undefined,

	load: async () => {
		const allWallets = await service.getAll()
		set({ wallets: allWallets })
	},

	setCurrentWallet: (wallet) => set({ currentWallet: wallet }),

	getWallet: async (walletId: string) => {
		const wallet = await service.get(walletId)
		set({ currentWallet: wallet })
	},

	createWallet: async (wallet: Wallet) => {
		const newWallet = await service.create(wallet)
		set((state) => ({ wallets: [...state.wallets, newWallet] }))
	},

	updateWallet: async (wallet: Wallet) => {
		const updatedWallet = await service.update(wallet)
		set((state) => ({
			wallets: state.wallets.map((w) => (w.id === updatedWallet.id ? updatedWallet : w)),
			currentWallet: state.currentWallet?.id === updatedWallet.id ? updatedWallet : state.currentWallet,
		}))
	},

	deleteWallet: async (walletId: string) => {
		await service.delete(walletId)
		set((state) => ({
			wallets: state.wallets.filter((w) => w.id !== walletId),
			currentWallet: state.currentWallet?.id === walletId ? undefined : state.currentWallet,
		}))
	},
}))

‍


Avec ce store on remarque qu'on va pouvoir facilement, dans n'importe quel environnement JavaScript, charger, définir, récupérer, créer, mettre à jour et supprimer des portefeuilles, tout en maintenant un état global pour l'ensemble des portefeuilles et du portefeuille courant.

‍

‍

Conclusion

Nous avons maintenant terminé ce deuxième article de cette série sur le développement d'une application web et mobile avec l'Architecture Hexagonale et le partage de la logique métier et des composants UI.

Dans cette deuxième partie nous avons vu comment travailler en TDD et surtout comment écrire de la logique métier sans avoir à ouvrir une quelque interface à l'exception du terminal pour les retours de tests.

Nous avons également eu un aperçu de comment nous allons interagir avec nos applications avec le coeur de l'application, via notre store Zustand. Nous irons plus loin à ce sujet dans le prochain article, la troisième partie : Partager de la logique métier et des composants entre le Web et le Mobile.

‍

Dans le monde numérique moderne, l'intégration d'un chat dans les applications mobiles joue un rôle crucial pour renforcer l'engagement et la satisfaction des utilisateurs.

‍

Avec des solutions comme Intercom, Crisp, et Brevo, offrir un support client en temps réel et faciliter la communication devient non seulement possible, mais aussi efficace. 

‍

Que vous soyez un développeur chevronné ou simplement curieux de comprendre comment ces systèmes s'intègrent dans les applications mobiles, cet article vous guidera à travers les avantages, les techniques d'intégration, et les meilleures pratiques pour utiliser le chat mobile. 

‍

En mettant l'accent sur des applications de messagerie adaptées aux besoins des utilisateurs et des entreprises, nous explorons comment ces outils transforment l'interaction numérique, rendant chaque conversation plus significative.

‍

Pourquoi intégrer un chat dans votre application mobile ?

L'intégration d'un système de chat dans une application mobile n'est pas seulement une fonctionnalité supplémentaire ; c'est une stratégie essentielle pour améliorer l'interaction utilisateur et offrir un support client sans précédent. Voici pourquoi l'ajout d'un chat à votre application mobile peut être un véritable atout pour votre entreprise.

‍

Amélioration de l'expérience utilisateur

Le chat en direct dans les applications mobiles crée une ligne de communication instantanée entre les utilisateurs et votre entreprise. Cela signifie que les questions, préoccupations et commentaires peuvent être adressés rapidement, améliorant ainsi l'expérience utilisateur (UX). Une réponse rapide peut transformer une expérience utilisateur médiocre en une expérience positive, augmentant la satisfaction et la fidélité des clients.

‍

Support client en temps réel

Avec l'intégration de solutions de chat telles qu'Intercom, Crisp ou Brevo, vous offrez un support client en temps réel directement depuis l'application. Cela élimine le besoin pour les utilisateurs de quitter l'application pour obtenir de l'aide. Un accès facile au support client non seulement résout les problèmes plus rapidement mais renforce également la confiance dans votre marque.

‍

Engagement accru (h3)

Les systèmes de chat permettent une communication bidirectionnelle qui peut être utilisée pour engager les utilisateurs. Que ce soit par des notifications push personnalisées, des offres spéciales ou des sondages, le chat peut servir de puissant outil d'engagement. En maintenant les utilisateurs engagés, vous augmentez les chances qu'ils utilisent votre application plus fréquemment et pour de plus longues périodes.

‍

Collecte de retours utilisateurs

Le chat offre une plateforme pour recueillir des commentaires précieux des utilisateurs en temps réel. Ces retours peuvent être utilisés pour améliorer l'application, corriger des bugs, et développer de nouvelles fonctionnalités qui répondent mieux aux besoins des utilisateurs. Une meilleure compréhension des désirs des utilisateurs conduit à une meilleure prise de décision et à des mises à jour de l'application plus pertinentes.

‍

Avantage concurrentiel

Dans un marché saturé, offrir un chat intégré dans votre application peut vous démarquer de la concurrence. Cela montre que vous êtes engagé à fournir un excellent service client et à faciliter la communication. Une telle fonctionnalité peut être un facteur décisif pour les utilisateurs lorsqu'ils choisissent entre votre application et celle d'un concurrent.

En intégrant un chat dans votre application mobile, vous ne faites pas que suivre une tendance ; vous investissez dans une meilleure expérience utilisateur, un support client amélioré, et une stratégie d'engagement plus forte. Ces éléments sont cruciaux pour le succès à long terme de toute application mobile.

‍

‍

Solutions de chat pour applications mobiles : vue d'ensemble

‍

L'adoption de solutions de chat pour applications mobiles est une étape cruciale vers l'amélioration de la communication et de l'engagement des utilisateurs. Ces solutions, telles qu'Intercom, Crisp, et Brevo, offrent une variété de fonctionnalités conçues pour répondre aux besoins des entreprises et de leurs utilisateurs. Voici une vue d'ensemble de ce que ces solutions de chat peuvent offrir et comment elles se comparent.

‍

Intercom

Intercom est largement reconnu pour sa plateforme de communication client intégrée, qui facilite le chat en direct, l'engagement des utilisateurs, et le support client. Son intégration dans les applications mobiles permet une communication fluide entre les utilisateurs et les représentants du service client, avec des fonctionnalités telles que les réponses automatisées et la segmentation des utilisateurs. Intercom se distingue par sa capacité à offrir des interactions personnalisées à grande échelle.

‍

Crisp

Crisp propose une solution de chat multicanal qui supporte non seulement le chat en direct mais aussi le courrier électronique, les SMS, et les réseaux sociaux. Ce qui le rend particulièrement attractif pour les applications mobiles, c'est sa simplicité d'utilisation et sa capacité à unifier toutes les communications client en un seul lieu. Crisp est idéal pour les entreprises cherchant à offrir une expérience utilisateur cohérente à travers différents canaux.

‍

Brevo

Brevo est une solution de chat mobile axée sur l'automatisation et l'intelligence artificielle. Elle permet aux entreprises de créer des bots de chat qui peuvent gérer des conversations de base, orienter les utilisateurs vers les ressources appropriées, et même effectuer des tâches simples. L'intégration de Brevo dans une application mobile peut considérablement réduire la charge de travail du service client tout en maintenant les utilisateurs engagés.

‍

Comparaison avec les applications de chat gratuites

Bien que les applications de chat gratuites comme WhatsApp ou Facebook Messenger offrent des moyens de communication efficaces, elles ne sont pas toujours idéales pour un usage professionnel en raison de leur manque de personnalisation et de contrôle. En comparaison, les solutions de chat payantes offrent des fonctionnalités avancées telles que l'analyse des données utilisateur, l'intégration avec d'autres outils professionnels, et un haut degré de personnalisation.

‍

Compatibilité avec Android et iOS

Une considération importante lors du choix d'une solution de chat pour une application mobile est sa compatibilité avec les systèmes d'exploitation Android et iOS. Intercom, Crisp, et Brevo offrent tous une excellente compatibilité, garantissant que les utilisateurs bénéficient d'une expérience de chat fluide, indépendamment de leur appareil.

‍

Intégration avec des comptes existants

La possibilité d'intégrer des solutions de chat avec des comptes existants, tels que les comptes Google ou Facebook, peut simplifier le processus de connexion pour les utilisateurs et améliorer l'expérience utilisateur. Ces intégrations peuvent également fournir aux entreprises des informations précieuses sur les préférences et les comportements des utilisateurs.

‍

En résumé, choisir la solution de chat appropriée pour votre application mobile dépend de plusieurs facteurs, y compris les besoins spécifiques de votre entreprise, le niveau de personnalisation souhaité, et les préférences de vos utilisateurs. En offrant une vue d'ensemble des options disponibles, cette section aide les développeurs et les décideurs à naviguer dans le paysage des applications de chat et à choisir celle qui convient le mieux à leur application mobile.

‍

Intégration Technique d'un Système de Chat

‍

L'intégration technique d'un système de chat dans une application mobile est une étape cruciale qui nécessite une attention particulière pour assurer une expérience utilisateur fluide et efficace. Cette section aborde les différentes méthodes d'intégration, en mettant l'accent sur l'intégration en webview, les solutions natives, et l'utilisation des SDK.

‍

Intégration en webview

L'utilisation d'une webview dans React Native permet d'intégrer facilement un chat web externe dans votre application en encapsulant la page web du chat dans un composant WebView.

‍

Exemple de code React Native (JSX) pour intégrer une webview :

‍

‍

Cet exemple montre comment charger une interface de chat web dans un composant WebView de React Native, permettant aux utilisateurs d'interagir avec le chat directement dans l'application.

‍

Solutions natives via des SDK

Pour une intégration plus profonde et native, vous pouvez utiliser les SDK fournis par des plateformes de chat comme Intercom, Crisp, ou Brevo. Ces SDK nécessitent souvent l'utilisation de modules natifs ou de wrappers disponibles pour React Native.

‍

Exemple d'intégration du SDK Intercom pour React Native :

‍

‍

Cet exemple montre comment initialiser et enregistrer un utilisateur avec Intercom dans votre application React Native, permettant une interaction native avec le service de chat.

‍

Utilisation des SDK

Les SDK spécifiques à chaque plateforme de chat, tels que ceux pour Crisp ou Brevo, peuvent être intégrés à React Native à travers des packages spécifiques ou des ponts natifs.

‍

Exemple d'intégration générique d'un SDK:

‍

‍

Bien que cet exemple soit générique, il illustre comment un SDK de chat pourrait être initialisé dans React Native. Consultez la documentation spécifique du SDK pour des instructions détaillées.

‍

Considérations importantes

• Sécurité et Confidentialité : Veillez à ce que le chat intégré offre un chiffrement de bout en bout et respecte les réglementations de protection de la vie privée des utilisateurs.

• Compatibilité : Testez l'intégration sur les différentes versions d'Android et iOS pour assurer une compatibilité et une performance optimales.

• Personnalisation : Utilisez les options de personnalisation fournies par le SDK pour harmoniser l'interface de chat avec le design de votre application.

‍

En intégrant un système de chat dans votre application React Native, vous offrez une valeur ajoutée significative à vos utilisateurs en facilitant la communication et en fournissant un support en temps réel. Les exemples de code fournis devraient vous aider à démarrer avec l'intégration, mais assurez-vous de consulter la documentation de chaque SDK pour des détails spécifiques à votre mise en œuvre.

‍

En conclusion, l'intégration d'un système de chat dans une application mobile est une démarche stratégique essentielle pour améliorer l'engagement des utilisateurs, fournir un support client en temps réel, et recueillir des feedbacks précieux. Avec des solutions de chat avancées comme Intercom, Crisp, et Brevo, les développeurs disposent d'outils puissants pour incorporer facilement ces fonctionnalités dans leurs applications mobiles, qu'elles soient développées avec React Native ou d'autres frameworks.

‍

L'utilisation de Webviews, l'intégration de SDK spécifiques, ou encore le déploiement de solutions natives, offre une flexibilité permettant de choisir l'approche qui convient le mieux aux besoins spécifiques de l'application et à son public cible. Chaque méthode d'intégration présente des avantages uniques, allant de la facilité de mise en œuvre à la personnalisation poussée, en passant par l'optimisation de l'expérience utilisateur.

‍

Il est crucial, cependant, de ne pas perdre de vue l'importance de la sécurité, de la confidentialité, et de la compatibilité lors de l'intégration de ces systèmes de chat. Ces aspects sont fondamentaux pour maintenir la confiance des utilisateurs et assurer le succès à long terme de l'application.

‍

L'avenir des applications mobiles réside dans la capacité à créer des expériences utilisateur riches et interactives. L'intégration d'un système de chat répond parfaitement à cette exigence, en transformant les interactions numériques en conversations significatives et engageantes. En tant que développeurs et décideurs, il est de notre responsabilité de tirer parti de ces technologies pour construire des applications qui non seulement répondent aux besoins actuels des utilisateurs mais anticipent également leurs attentes futures.

‍

Que vous soyez un développeur expérimenté ou un entrepreneur novateur, intégrer un système de chat dans votre application mobile est un pas en avant vers la création d'une expérience utilisateur véritablement dynamique et connectée. Les possibilités sont vastes, et avec les bonnes pratiques et les outils appropriés, votre application peut devenir un espace où les utilisateurs se sentent écoutés, soutenus, et engagés.

‍

L'origine

Le Test-Driven Development plus communément appelé TDD n'a pas été inventé par une seule personne mais par plusieurs développeurs. Kent Beck est souvent la personne la plus affiliée au TDD parce qu'il est celui qui l'a popularisé lors de ses travaux sur la méthodologie Extreme Programming à la fin des années 90. Néanmoins il est important de rappeler qu'il n'est pas le créateur de l'outil qu'est le TDD, il a été mis en place pour tout un tas de personne, dont notamment Martin Fowler (co-auteur du Manifeste Agile) ou encore Ward Cunningham et Ron Jeffries qui ont fondé l'Extreme Programming avec Kent Beck.

Un outil de travail

L'outil

Le TDD est un outil de travail qui permet au développeur de coder en étant guidé par les tests. Il permet d'avancer étape par étape, petit pas par petit pas, pour avancer vers une solution toujours plus fiable.

Cette solution plus fiable est notamment due à sa forte proximité avec les principes SOLID. En effet, le TDD facilite la mise en place des principes SOLID. En écrivant d'abord des tests, il est plus naturel de concevoir un code simple et cohérent qui respecte les principes tels que l'encapsulation, le découplage, la gestion des dépendances et la séparation des responsabilités. On se retrouve plus naturellement avec des modules indépendants et l'injection de dépendances, ce qui conduit à du code plus propre.

Le TDD et les principes SOLID vont donc de pair pour une conception logicielle de qualité.

1. Nous avons une première phase (rouge sur le schéma) où nous devons écrire un test qui échoue, basé sur une spécification. NB : on n'écrit pas de code de production (code final) tant que le test n'est pas en échec.
2. La deuxième phase (verte sur le schéma) consiste à faire passer le test en succès en écrivant du code de production et tout en restant le plus simple possible. NB : on écrit uniquement le code nécessaire pour faire passer le test et sans retourner dans le code du test.
3. La dernière phase (bleue sur le schéma) concerne le refactoring. On met à jour le code en appliquant les bonnes pratiques, le clean code, etc. Une fois que le refactoring est fait, si les tests passent toujours, on conserve le refactor et on passe aux prochaines spécifications, sinon, on annule le refactor et on essaye autre chose. NB : ne doit jamais effectuer de refactoring dans les autres phases, seulement ici.

L'approche TDD est un développement itératif et incremental qui met l'accent sur la qualité du code.

Le manifeste

Le TDD respecte certains principes qui sont :

• Baby steps instead of large-scale changes

On avance petit pas par petit pas pour avoir une boucle de feedback rapide et régulière.

• Continuous refactoring instead of late quality improvements

On améliore le code en continue, on s'en occupe tout de suite parce qu'un refactor annoncé pour plus tard n'arrive finalement en général jamais.

• Evolutionary design instead of big design up front

On développe ce qui est nécessaire et suffisant et on évolue progressivement.

• Executable documentation instead of static documents

Les tests mis en place pendant le TDD sont en réalité une documentation executable. L'idée est de lier la documentation avec le code pour s'assurer qu'elle est bien à jour et maintenue.

• Minimalist code instead of gold-plated solution

Un code simple et qui fonctionne plutôt qu'une solution surdimensionnées avec un niveau de complexité bien trop élevé et pas nécessaire.

Le test propre

Given When Then

L'approche Given When Then est basée sur une convention développée dans le cadre du Behaviour-Driven Development autrement appelé BDD. Il s'agit d'une approche de développement axée sur la collaboration et la spécification du comportement à travers ds scénarios clairs et compréhensibles.

En utilisant cette convention on divise le test en trois parties :

1. Given, la condition préalable au test
2. When, l'exécution du système testé
3. Then, le comportement attendu

Exemple : Given user is not logged in When user logs in Then user is logged in successfully

Should When

L'approche Should When est une convention de nommage facile à lire et plus largement utilisée.

En utilisant cette convention on divise le test en deux parties :

1. When, la condition préalable au test
2. Should, le comportement attendu

Exemple : Should have user logged in When user logs in

Arrange Act Assert

Le modèle Arrange Act Assert autrement appelé AAA est un pattern descriptif et révélateur des intentions pour structurer le test.

Le test est alors organisé de la manière suivante :

1. La partie Arrange contient la logique de configuration du test. C'est ici qu'on initialise le test.
2. La partie Act execute le système que l'on souhaite tester. C'est ici qu'on fait l'appel d'une fonction, d'un composant, d'un call API, etc.
3. La partie Assert, vérifie que le système testé se comporte comme prévu. C'est ici qu'on vérifie que le résultat obtenu correspond au résultat attendu.

Exemple :

F.I.R.S.T.

Le principe F.I.R.S.T. est un ensemble de principes qui définissent les caractéristiques d'un test propre et de qualité.

Ces caractéristiques sont les suivantes :

• Fast, un test doit être rapide et efficace de manière à pouvoir être exécuté fréquemment pour avoir un feedback régulier
• Independent, les tests doivent être indépendants les uns des autres afin d'être exécutable individuellement et efficacement
• Repeatable, un test doit être répétable dans n'importe quel environnement et à tout moment
• Self-Validating, les tests doivent retourner un succès ou un échec afin de vérifier lui même si l'exécution du test a réussi ou échoué sans évaluation manuelle
• Timely, les tests doivent être écrit avant ou en même temps que le code de production. ils doivent être maintenus et exécutés régulièrement

Quand l'utiliser ?

Quand ne pas l'utiliser plutôt !

Il n'est pas nécessaire et pas utile de faire du TDD quand on a pas de spécifications, quand les tests n'apportent rien, quand les tests sont trop lents, quand il n'y a pas de logique.

La démo

L'incontournable Fizz Buzz

Le Fizz Buzz est un exercice populaire qui permet d'appréhender la méthode TDD. Ce n'est qu'un échantillon et qu'un début de la méthode, mais ça reste intéressant.

Les spécifications sont les suivantes :

• On commence à compter à partir de 1 jusqu'à 100
• Lorsqu'on rencontre un nombre divisible par 3, on retourne "Fizz"
• Lorsqu'on rencontre un nombre divisible par 5, on retourne "Buzz"
• Lorsqu'on rencontre un nombre divisible par 3 et par 5, on retourne "Fizz-Buzz"

Nous allons utiliser le TypeScript pour mettre en place cet algorithme et le tester.

Première spécification

On créé un fichier test fizz-buzz.test.ts et on créé notre premier test qui va gérer la spécification où on teste le nombre 1.

Ici, le test ne passe pas parce qu'on a pas encore créé la fonction fizzBuzz() et encore moins l'algorithme associé. Nous sommes donc à la première phase du TDD, la phase rouge, celle où on écrit un test qui échoue.

On va maintenant passer à la deuxième phase du TDD, celle où on va faire passer le test au vert. Pour cela, on va créer le fichier fizz-buzz.ts et écrire le code permettant de gérer notre cas de spécification.

Ici, on pourrait avoir tendance à faire un return String(n) directement, mais TDD nous dit de commence par écrire le code le plus simple possible pour faire passer le test au vert, et en réalité le plus simple et rapide et de tout simplement retourner 1 directement.

On va passer au prochain test qui est de tester l'input 2.

Le test échoue parce qu'on a pas encore géré ce cas dans notre fonction. On retourne donc dans notre fonction et on essaye de résoudre ce cas de la manière la plus simple et rapide.

Ici, encore une fois, le plus rapide est de retourner 2 si on a 2 en input.

Maintenant on arrive à la troisième et dernière phase du TDD, celle du refactor. En effet, actuellement nos tests passent avec succès, le code est simple, mais il pourrait l'être encore plus en appliquant de bonnes pratiques.

On va donc revenir sur notre fonction fizzBuzz() sans modifier les tests.

Notre fonction est maintenant simple, propre et concise et les tests sont toujours verts. Notre refactor est donc réussit, on peut passer à la prochaine spécification.

Deuxième spécification

Nous devons maintenant faire en sorte de retourner Fizz si l'input est divisible par 3.

Le test échoue, on va maintenant gérer le cas du Fizz dans la fonction.

Le code le plus simple pour retourner  Fizz quand on a 3 et de tester si n === 3.

On va maintenant gérer un deuxième cas où on a un nombre divisible par 3.

Le test échoue, on met à jour le code.

Le code le plus simple pour retourner Fizzquand on a 3 ou 6 et de faire un ||, mais on se rend bien compte qu'on peut améliorer le code en utilisant le modulo de 3. Les tests sont tous verts, donc on peut se permettre de passer à la phase de refactor en modifiant uniquement le code de la production.

Refactor terminé, tous les tests sont verts, on peut passer à la prochaine spécification.

Troisième spécification

Nous devons maintenant faire en sorte de retourner Buzz si l'input est divisible par 5.

On va aller un peu plus vite, mais le procédé est le même, on va d'abord faire un test avec un input 5 puis 10, puis refactor.

‍

‍

Dernière spécification

Nous devons maintenant faire en sorte de retourner Fizz-Buzz si l'input est divisible par 3 et par 5.

Comme pour les spécifications précédentes, on va faire un test avec un input 15 puis 30 et enfin refactor.

‍

‍

Et voilà !

Le mot de la fin

Stop aux amalgames ! Le TDD n'est pas un outil pour avoir une bonne couverture de code avec les tests, ce n'est pas simplement "faire des tests". Le TDD est un outil dont le but est de guider le développeur vers un objectif. Il permet de donner un feedback régulier afin de s'assurer qu'on est toujours sur la bonne voie. Il faut le voir comme un GPS, qui nous donne des directions à suivre (tourner à droite, aller tout droit pendant 2km, etc.) jusqu'à atteindre un objectif.

Les dédicaces

• Kent Beck - Wikipédia
• TDD Manifesto
• "Test-Driven Development by Example" de Kent Beck
• "Clean Code: A Handbook of Agile Software Craftsmanship" de Robert C. Martin
• Artisan Développeur - Benoit Gantaume
• Wealcome - Michaël Azerhad
• Craft Academy - Pierre Criulanscy

‍