GherkinTesting

Le BDD (Behavior-Driven Development) est un standard dans l'industrie. Ruby a Cucumber, Python a Behave, .NET a SpecFlow. Et Swift ?

XCTest-Gherkin — Vieux, mal maintenu, API datée. CucumberSwift — Objective-C sous le capot, fuites mémoire, performances catastrophiques. Quick/Nimble — Pas vraiment du Gherkin, juste du describe/it.

Résultat : les équipes iOS qui veulent faire du BDD galèrent. Elles bricolent des solutions partielles, importent des frameworks bancals, ou abandonnent tout simplement.

GherkinTesting change ça. Un vrai framework BDD moderne, construit avec les Swift Macros, compatible Swift Testing, pensé pour les équipes de 2025.

Pas de parsing runtime, pas de reflection, pas de magie noire. GherkinTesting utilise les Swift Macros pour transformer vos types en suites de tests à la compilation.

La macro @Feature transforme cette struct en suite de tests. Chaque scénario du fichier .feature est exécuté en utilisant les steps définis par @Given, @When, @Then.

Chargez vos features depuis plusieurs sources :

Les Cucumber Expressions offrent une alternative lisible aux regex. Le framework supporte les types natifs et les types custom :

Définissez vos propres types de paramètres dans gherkinConfiguration :

Les Data Tables permettent de passer des données tabulaires à un step :

L'API DataTable expose headers, dataRows, asDictionaries et empty pour manipuler les données.

Les Doc Strings permettent de passer du contenu multiligne, avec un media type optionnel :

Un step peut combiner des paramètres Cucumber Expression et une DataTable :

Les Scenario Outlines permettent de tester le même scénario avec différentes données. Les tags sur les blocs Examples: offrent un filtrage granulaire :

Gherkin supporte 70+ langues. Vos fichiers .feature peuvent être en français, anglais, allemand, japonais... Il suffit d'ajouter la directive # language: en première ligne :

Les définitions de steps restent en Swift — seuls les fichiers .feature changent de langue.

Contrôlez le cycle de vie de vos tests avec @Before et @After à différentes portées :

Les hooks supportent les paramètres order: pour contrôler l'ordre d'exécution et tags: pour un déclenchement conditionnel :

Portées disponibles : .feature, .scenario, .step. Les @Before s'exécutent en FIFO, les @After en LIFO.

Organisez et filtrez vos tests avec des expressions booléennes :

Expressions supportées : @tag, not @tag, @a and @b, @a or @b, parenthèses. Les scénarios filtrés apparaissent comme .skipped dans les rapports.

Réutilisez des steps entre features avec @StepLibrary :

Chaque library est instanciée fraîchement par scénario via retyped() pour garantir l'isolation de l'état.

Le mot-clé Rule: permet de grouper des scénarios sous une contrainte métier :

Les scénarios dans une Rule héritent du Background de la feature.

Générez des rapports compatibles avec tous les outils CI/CD via le paramètre reports: de @Feature :

Trois formats disponibles :

Les rapports sont écrits automatiquement dans /tmp/swift-gherkin-testing/reports/ après exécution des tests. Vous pouvez personnaliser le chemin :

Vérifiez que tous vos steps sont implémentés sans exécuter les tests :

En mode dry-run, le framework inspecte les scénarios et génère des StepSuggestion pour chaque step non implémenté, avec l'expression Cucumber et la signature Swift suggérées.

Le framework est entièrement compatible avec les global actors de Swift. Vous pouvez annoter vos features, step handlers ou step libraries :

Fonctionne aussi avec des @GlobalActor custom et des appels cross-isolation via await.

Puis ajoutez la dépendance à votre cible de tests :

Le framework s'intègre nativement avec les pipelines CI. Un workflow minimal :

Ajoutez la collecte des rapports JUnit XML en artifact :

GherkinTesting fait partie d'un ensemble d'outils complémentaires :

Trois outils, un workflow BDD complet en Swift.