L'injection de dépendance est-elle essentielle pour les tests unitaires?

L'utilisation de l'injection de dépendance (ID) est-elle essentielle pour les tests unitaires?

Je ne peux pas penser à une autre alternative pour isoler le code afin qu'il puisse être testé. En outre, tous les exemples que j'ai vus utilisent ce modèle. Est-ce parce que c'est la seule option viable ou existe-t-il d'autres alternatives?

DI facilite grandement les tests unitaires. Mais vous pouvez toujours écrire des tests unitaires sans DI. De nombreux tests unitaires ont déjà été écrits avant la généralisation de l'ID. (Bien sûr, certaines de ces techniques utilisées sont identiques ou très similaires à DI sans savoir qu’elle a un nom compliqué :-)

J'ai moi-même beaucoup utilisé, par exemple, les interfaces et les usines avant de connaître le DI. Le nom actuel de la classe de fabrique peut avoir été lu dans un fichier de configuration ou transmis au SUT en tant qu'argument.

Une autre approche consiste à utiliser des singletons (ou des données globalement accessibles). Oui, je sais que ce n'est pas recommandé par beaucoup (y compris moi-même) en général. Néanmoins, il peut être viable dans des situations spécifiques, notamment si le singleton contient des données de configuration statiques qui ne sont pas spécifiques à un cas de test, mais diffèrent entre l'environnement de production et l'environnement de test. Bien sûr, il a ses problèmes connus, donc DI est supérieur si vous pouvez l'utiliser. Mais souvent (par exemple, dans les systèmes existants), vous ne pouvez pas.

Parler qui, Travailler efficacement avec Legacy Code décrit beaucoup de trucs pour obtenir le code existant couvert par des tests. Beaucoup d'entre eux ne sont pas agréables et ne constituent pas une solution à long terme. Mais ils vous permettent de créer les premiers tests unitaires de valeur sur un système par ailleurs indéfectible ... ce qui vous permet de commencer la refactorisation et, éventuellement, d’introduire DI.

Le découplage est essentiel pour les tests unitaires. DI est un excellent moyen de réaliser le découplage.

Selon les technologies que vous utilisez, vous pouvez isoler des dépendances sans utiliser DI. Par exemple, dans le monde .NET, Moles vous permet d'isoler des dépendances sans le motif DI.

Cela dit, je pense que ces frameworks d’isolation sont écrits et destinés à des situations de code comportant des dépendances externes (système de fichiers, base de données, etc.). C'est-à-dire que le fait de pouvoir faire cela ne veut pas dire qu'il le devrait.

L'injection de dépendance permet les tests unitaires, mais elle permet également de modifier le comportement d'un objet sans modifier le code de cet objet (principe ouvert / fermé). Ainsi, il ne s'agit pas uniquement d'un code testable, mais d'un code flexible. J'ai généralement constaté qu'il existe une forte corrélation entre le code maintenable / flexible et le code testable.

Non, l'ID n'est pas indispensable pour les tests unitaires, mais cela aide beaucoup.

Vous pouvez utiliser des usines ou des localisateurs et tester comme vous le feriez avec DI (mais pas aussi élégant et nécessiterait plus de configuration).

En outre, les objets fantaisie seraient importants dans les systèmes existants, dans lesquels de nombreux appels sont délégués à des fonctions plutôt qu'à des dépendances. (Les objets fantaisie peuvent également être largement utilisés dans une configuration appropriée)

Il peut y avoir des configurations où les tests sont presque impossibles. Mais cela ne dépend pas de l'utilisation ou non de l'injection de dépendance.

Non , l'injection de dépendance n'est pas indispensable pour les tests unitaires.

L'injection de dépendance est utile si vous avez une classe qui a besoin d'une instance de classe dépendante pour effectuer un sous-traitement. Au lieu de DI, vous pouvez séparer la logique d'une méthode métier en une partie de collecte de données (qui n'est pas testable par unité) et une partie de calcul qui peut être testée en unité.

Exemple (utilisation de DI) Cette implémentation dépend de Employee, Account, ...

 bool hasPermissionToTransferMoney(Employee employee, Account from, Account to, Money amount)
 {
     if (amount > 100 && employee.isStudent())
        return false;
     if (to.getOwner().getFamiliyName() == employee.getFamilyName() && ...
        return false; // cannot transfer money to himself;
     ...
 }

Après séparation de la collecte et du calcul des données:

 bool hasPermissionToTransferMoney(Employee employee, Account from, Account to, Money amount)
 {
     return hasPermissionToTransferMoney(employee.isStudent(), employee.getFamilyName(), to.getOwner().getFamilyName(), ...);
 }

 // the actual permission calculation
 static bool hasPermissionToTransferMoney(boolean isStudent, string employeeFamilyName, string receiverFamilyName, ...)
     if (amount > 100 && isStudent)
        return false;
     if (receiverFamilyName == employeeFamiliyName && ...
        return false; // cannot transfer money to himself
     ...
 }

La partie calcul peut être facilement testée sans injection de dépendance.

• L'injection de dépendance n'est pas essentielle pour les tests unitaires

• L'inversion du contrôle est en revanche essentielle lorsque vous souhaitez échanger une mise en œuvre contre une autre.

Oui, il existe des alternatives à l'utilisation de DI pour l'isolement.

Une alternative consiste à utiliser des fabriques ou un ServiceLocator pouvant être configuré à partir de tests pour renvoyer des objets fictifs au lieu d'objets réels.

Une autre consiste à utiliser un cadre d'isolation approprié ou un outil moqueur. De tels outils existent pour à peu près tous les langages de programmation modernes (pour Java, C #, Ruby et Python, au moins). Ils peuvent isoler une classe en cours de test de la mise en œuvre d'autres classes / types, même lorsque la classe testée instancie directement ses dépendances.