Comment puis-je tester une classe Singleton avec DUnit?

Question

Ou vaut-il mieux utiliser un autre motif de conception?

Answer 1

Répondu à une question similaire il y a quelques jours ici, se moquant un singleton . Le message d'origine est pour C # .Net en ce qui concerne le comportement moqueur d'un singleton, mais devrait quand même s'appliquer.

En ce qui concerne le modèle de singleton, il n’ya rien de mal en soi - dans de nombreux cas, nous souhaitons centraliser la logique et les données. Cependant, il existe une très grande différence entre un singleton et une classe statique. Construire votre singleton en tant que code statique de classe statique pouvant être mis en œuvre pour chaque consommateur de votre application, ce qui rend les tests unitaires très difficiles!

Ce que vous voulez faire est de définir une interface pour votre singleton, exposant les méthodes que vos consommateurs peuvent utiliser. adopté fait référence à une classe d'implémentation par vos clients, à qui appartient-il de l'instancier [il s'agit généralement de votre application ou d'un conteneur si vous connaissez bien Dependency Injection \ Inversion of Control].

C’est ce cadre, quel qu’il soit, qui instancie les consommateurs, est chargé de s’assurer qu’une seule et unique instance flotte. Ce n’est vraiment pas un si grand saut d’une classe statique à une référence d’interface [comme le montre le lien ci-dessus], vous perdez simplement la commodité d’une instance accessible globalement - je sais que les références globales sont terriblement séduisantes, mais Luke tourna le dos à la Dark Side, vous aussi!

De manière générale, les meilleures pratiques suggèrent d'éviter les références statiques et encouragent la programmation par rapport aux interfaces. Rappelez-vous qu'il est toujours possible d'appliquer le motif singleton avec ces contraintes. Suivez ces instructions et vous ne devriez rencontrer aucun problème pour tester votre travail:)

J'espère que ça aide!

singleton! = classe statique publique , plutôt singleton == instance unique

Answer 2

Le manque de testabilité est l’un des inconvénients majeurs du modèle Singleton classique (méthode de classe statique renvoyant une instance). En ce qui me concerne, c'est une justification suffisante pour re-concevoir tout code qui utilise Singletons pour utiliser un autre design.

Si vous devez absolument avoir une instance singulière, alors Dependency Injection et l’écriture sur une interface, comme le suggère Johnny g, sont définitivement la voie à suivre.

Answer 3

j'utilise le modèle suivant quand j’écris des singletons statiques que je peux me moquer. Le code est Java, mais je pense que vous aurez une idée. Le principal problème avec cette approche est que vous devez assouplir le constructeur pour qu'il soit protégé par le paquet (ce qui annule en quelque sorte un véritable singleton). Remarque: le code s'applique à la possibilité de se moquer de votre " statique " code pas nécessairement simplement l'appelant

Answer 4

Je n'utilise généralement que des singletons pour les objets Flyweight ou des objets de valeur similaires. Rechercher dans un conteneur IoC (comme indiqué ci-dessus) est probablement un meilleur moyen de gérer un objet partagé qu'un singleton.

Considérons que dans Smalltalk (d'où proviennent beaucoup de ces motifs), vrai et faux sont tous deux singletons:)

Answer 5

Si vous devez utiliser un singleton (et il y a des raisons de le faire ... mais j'essayerais toujours de l'éviter si possible). Je recommanderais d'utiliser un conteneur IOC pour le gérer. Je ne sais pas s'il y en a un pour Delphi ou non. Mais en Java, vous pouvez utiliser Spring, en .NET, vous pouvez utiliser Windsor / Castle. Un conteneur IOC peut conserver le Singleton et enregistrer différentes implémentations à des fins de test.

C'est probablement un sujet trop vaste pour entrer ici au-delà de cet extrait.