BDD sur Swift : comment écrire des tests que le métier comprend

Pourquoi les tests classiques ne suffisent pas, et qu'est-ce que le BDD

Chaque développeur iOS a déjà vécu cette situation : vous avez écrit une centaine de tests unitaires, la couverture est de 90 %, mais lors de la prochaine démo, le manager dit : « Et pourquoi rien ne se passe quand on clique sur ce bouton ? ». Vous regardez le code — tout fonctionne. Le problème est que les tests unitaires vérifient le code, pas le comportement du système. C'est là qu'intervient le BDD (Behaviour-Driven Development) — une méthodologie qui efface la frontière entre les tests « techniques » et la « logique métier ».

Le BDD sur Swift n'est pas qu'un terme à la mode. C'est une façon d'écrire des tests que non seulement un développeur, mais aussi un analyste, un testeur ou même un client peut lire. Dans cet article, nous allons voir comment intégrer le behaviour-driven development dans votre projet iOS en utilisant les frameworks Quick et Nimble, et montrer des exemples concrets en Swift.

Qu'est-ce que le BDD en termes simples

Imaginez que vous n'écrivez pas des tests, mais un scénario de film. Dans le scénario, il y a des personnages (utilisateur, système), des événements (clic sur un bouton, envoi d'une requête) et un résultat attendu (apparition d'une alerte, mise à jour de l'interface). Le BDD, c'est exactement ce « scénario », mais pour votre application.

L'idée principale : les tests doivent décrire le comportement du système du point de vue de l'utilisateur. Au lieu de « la méthode saveUser() retourne true », vous écrivez « lorsque l'utilisateur saisit un email valide et clique sur "Enregistrer", le système affiche le message "Succès" ».

En quoi le BDD diffère du TDD

Beaucoup confondent le BDD avec le TDD (Test-Driven Development). La différence est simple :

• TDD — on écrit un test, puis le code, puis on refactorise. L'accent est mis sur la correction de l'implémentation.
• BDD — on écrit un scénario de comportement, puis le code qui implémente ce comportement. L'accent est mis sur la valeur pour l'utilisateur.

Le BDD est une évolution du TDD. Si le TDD répond à la question « le code fonctionne-t-il correctement ? », le BDD répond à « le code fait-il ce dont le métier a besoin ? ».

Outils pour le BDD sur Swift

Dans le monde Swift, il y a deux piliers principaux pour le behaviour-driven development :

• Quick — un framework pour écrire des tests dans le style BDD. Il remplace le XCTest standard et fournit une syntaxe describe/context/it.
• Nimble — une bibliothèque de « matchers » (vérifications). Au lieu de XCTAssertEqual, vous écrivez expect(value).to(equal(5)) — cela se lit comme une phrase anglaise.

Ces outils fonctionnent parfaitement ensemble et permettent d'écrire des tests qui ressemblent à une spécification.

Installation de Quick et Nimble via Swift Package Manager

Ajoutez les dépendances dans votre Package.swift ou via Xcode : File → Add Packages → saisissez l'URL du dépôt Quick : https://github.com/Quick/Quick.git et Nimble : https://github.com/Quick/Nimble.git.

Exemple pour Package.swift :

// swift-tools-version:5.9import PackageDescription

let package = Package(    name: "MyApp",    dependencies: [        .package(url: "https://github.com/Quick/Quick.git", from: "7.0.0"),        .package(url: "https://github.com/Quick/Nimble.git", from: "13.0.0"),    ],    targets: [        .target(name: "MyApp"),        .testTarget(            name: "MyAppTests",            dependencies: ["MyApp", "Quick", "Nimble"]        )    ])

Écrire notre premier test BDD en Swift

Supposons que nous ayons un simple LoginService qui vérifie le nom d'utilisateur et le mot de passe. Au lieu d'écrire un XCTest ennuyeux, créons un test dans le style BDD.

Code du service (pour le contexte)

class LoginService {    func authenticate(username: String, password: String) -> Result<User, LoginError> {        guard !username.isEmpty else { return .failure(.emptyUsername) }        guard !password.isEmpty else { return .failure(.emptyPassword) }        guard pas