Pourquoi ne Mockito pas se moquer des méthodes statiques?

Question

J'ai lu quelques discussions ici sur les méthodes statiques, et je crois que je comprends les problèmes de mauvaise utilisation/utilisation excessive de méthodes statiques peuvent causer. Mais je n'ai pas vraiment aller au fond de pourquoi il est difficile de se moquer des méthodes statiques.

Je sais que d'autres se moquant de cadres, comme PowerMock, peut le faire, mais pourquoi ne peut-Mockito?

J'ai lu cet article, mais l'auteur semble être religieusement contre le mot static, c'est peut-être mon manque de compréhension.

Une explication facile/lien serait génial.

Answer 1

Je pense que la raison peut être que l'objet fantaisie bibliothèques se moque de créer par créer dynamiquement des classes au moment de l'exécution (à l'aide de cglib). Cela signifie qu'ils soit de mettre en œuvre une interface au moment de l'exécution (c'est ce que EasyMock fait si je ne me trompe pas), ou qu'ils héritent de la classe pour se moquer (c'est ce que Mockito fait si je ne me trompe pas). Les deux approches ne fonctionnent pas pour les membres statiques, puisque vous ne pouvez pas remplacer l'utilisation de l'héritage.

La seule façon de se moquer de la statique est de modifier la classe de byte code au moment de l'exécution, qui, je suppose, est un peu plus que de l'héritage.

C'est je pense à elle, pour ce que ça vaut...

Answer 2

Si vous avez besoin de se moquer d'une méthode statique, il est un indicateur fort pour une mauvaise conception. Habituellement, vous vous moquez de la dépendance de votre classe-sous-essai. Si votre classe sous test se réfère à une méthode statique, comme java.util.Math#péché par exemple - cela signifie que la classe sous test doit exactement cette mise en œuvre (de précision vs vitesse par exemple). Si vous voulez abstrait à partir d'un béton sinus de la mise en œuvre, vous avez probablement besoin d'une Interface (vous voyez où ça va)?

Answer 3

J'ai sérieusement ne pense qu'il est odeur de code si vous avez besoin de se moquer des méthodes statiques, trop.

• Méthodes statiques pour accéder à la fonctionnalité commune? -> Utiliser une instance du singleton et injecter que
• Troisième partie du code? -> L'envelopper dans votre propre interface/délégué (et, si nécessaire, faire un singleton, trop)

La seule fois que cela paraît exagéré pour moi, est libs comme la Goyave, mais vous ne devriez pas avoir à se moquer de ce genre de toute façon parce que c'est une partie de la logique... (des trucs comme Iterables.transformer(..))
De cette façon, votre propre code reste propre, vous pouvez vous moquer de toutes vos dépendances de manière propre, et vous avez un anti corruption couche contre les dépendances externes. J'ai vu PowerMock dans la pratique, et de toutes les classes dont nous avions besoin pour ont été mal conçus. Aussi l'intégration de PowerMock parfois causé de sérieux problèmes
(par ex. https://code.google.com/p/powermock/issues/detail?id=355)

PS: en est de Même pour les méthodes privées, trop. Je ne pense pas que les tests doivent connaître le détail des méthodes privées. Si une classe est tellement complexe qu'il tente de se moquer privée méthodes, c'est probablement un signe de diviser la classe...

Answer 4

Dans certains cas, les méthodes statiques ne peuvent être difficiles à tester, surtout si elles doivent être l'objet de moqueries, ce qui est pourquoi la plupart des moqueries des cadres ne les supportent pas. J'ai trouvé ce blog très utile dans la détermination de la façon de se moquer des méthodes statiques et les classes.