Swift a été conçu pour être sûr - prenant en charge la réflexion en lecture seule. Ainsi, il n'y a aucun moyen de modifier votre programme à l'exécution. Dans l'ensemble, c'est bien, le code est exécuté comme prévu et les autres composants ne peuvent pas le modifier. Mais pour en revenir à notre sujet, tous les frameworks moqueurs sont construits sur la réflexion pour pouvoir changer de classes, de types et d'objets lors de l'exécution.

Ce langage a besoin de ses super-héros pour écrire du code testable, et nous les connaissons bien — protocoles et extensions ! Quelle que soit l'implémentation - classe, énumération ou structure - le but des protocoles demeure - définir des abstractions et ajouter de nouvelles fonctionnalités aux types, même ceux que nous ne devons pas.

Qu'est-ce qu'on peut faire pour se moquer ?

Utilisez la méta-programmation pour générer une implémentation fictive complète.

Il existe de nombreuses bibliothèques qui font le travail de simulation pour les tests unitaires, la plupart sont Cuckoo et swifyMocky .

Dans cet article, je vais donner un aperçu de la façon dont nous pouvons faire la moquerie en utilisant SwiftyMocky.

SwiftyMocky

https://github.com/MakeAWishFoundation/SwiftyMocky

Avantages

• Se moquer automatiquement des protocoles Swift
• Prise en charge des génériques
• Installation simple et légère
• Bonne documentation
• Syntaxe agréable et facile (qui utilise la saisie semi-automatique)

• Marquer les protocoles à moquer
• Chaque protocole dans les répertoires source, ayant cette annotation, sera ajouté à Mock.generated.swift

• Toutes les simulations ont une méthode donnée (accessible à la fois en tant que méthode d'instance ou fonction globale), avec une syntaxe facile à utiliser, permettant de spécifier quelles doivent être les valeurs de retour pour des méthodes données (basées sur des attributs spécifiés)

• Tous les mocks ont une méthode de vérification (accessible à la fois en tant que méthode d'instance ou fonction globale), avec une syntaxe facile à utiliser, permettant de vérifier si une méthode a été appelée sur mock et combien de fois. Il fournit également un moyen pratique de spécifier si les attributs de méthode sont importants (et lesquels)
• Tous les mocks ont une méthode perform (accessible à la fois en tant que méthode d'instance ou fonction globale), avec une syntaxe facile à utiliser, permettant de spécifier la fermeture, qui sera exécutée lors de l'appel de la méthode stub

Installer

• Installer à l'aide de Cocoapods
• Installer CLI pour une génération facile de maquettes

> médecin swiftymocky # valider votre configuration

> Swiftymocky génère # génère des simulacres

• La génération de mocks est basée sur le fichier Mockfile.yml avec la possibilité d'exclure les règles de lint rapides à l'aide d' exclusSwiftLintRules

Nous, en tant que développeurs, n'avons pas tellement d'outils pour nous moquer de Swift, avec des limites strictes en raison de l'accès à l'exécution limité par la langue. Et nous arrivons ici à la question critique - utiliser ou non des cadres externes pour se moquer.

L'oncle Bob bien connu continue de ne pas les utiliser autant que possible; il déclare : « Le moment où vous commencez à avoir besoin d'un cadre de simulation est le moment même où le couplage entre vos tests et le code devient trop élevé. Après cela, cependant, vous devez vous efforcer de maintenir le couplage entre votre code et vos tests suffisamment bas pour ne pas avoir à utiliser très souvent le framework moqueur.

Merci pour la lecture! Si vous avez aimé cet article, merci d'applaudir pour que d'autres personnes puissent le lire aussi :)

Bon codage :v: