JUnit 4 PermGen taille de débordement lors de l'exécution des tests dans Eclipse et Maven2

@Brice dit, les problèmes avec la PermGen seront à venir à partir de votre utilisation extensive de la moqué des objets. Powermock et Mockito à la fois de créer une nouvelle classe qui se trouve entre la classe se moquaient et votre code de test. Cette classe est créée au moment de l'exécution et chargés dans le PermGen, et est (pratiquement) jamais été retrouvé. Donc votre problème avec la PermGen space.

À votre question:

1) le Partage de variables statiques est considéré comme une odeur de code. Il est nécessaire, dans certains cas, mais il introduit depdendencies entre les tests. Test Un doit s'exécuter avant le test B.

2) l'Utilisation de méthodes statiques pour retourner un moqué de l'objet n'est pas vraiment une odeur de code, c'est un attern qui est souvent utilisé. Si vraiment vous ne pouvez pas augmenter votre permgen space, vous avez un certain nombre d'options:

Utiliser un pool d'objets fantaisie, avec PowerMock#reset() lorsque la maquette est mis de nouveau dans la piscine. Cela permettrait de réduire le nombre de créations que vous faites.

Deuxièmement, vous avez dit que vos cours sont finales. Si c'est modifiable, vous pouvez simplement utiliser une classe anonyme dans le test. Ce nouveau coupe vers le bas sur la quantité de permgen space utilisé:

Foo myMockObject = new Foo() {
     public int getBar() { throw new Exception(); }
}

Troisièmement, vous pouvez introduire une interface (utilisation de Refactor->Extrait de l'Interface dans Eclipse), ce qui permet ensuite s'étendre à une classe vide qui ne fait rien. Puis, dans votre classe, vous faites comme ci-dessus. J'utilise cette technique beaucoup, parce que je trouve ça plus facile à lire:

public interface Foo {
  public int getBar();
}

public class MockFoo implements Foo {
  public int getBar() { return 0; }
}

alors dans la classe:

Foo myMockObject = new MockFoo() {
     public int getBar() { throw new Exception(); }
}

Je dois admettre que je ne suis pas particulièrement fan de se moquer, je ne l'utilise que lorsque cela est nécessaire, j'ai tendance à prolonger la classe avec une classe anonyme ou créer une véritable MockXXX classe. Pour plus d'informations sur ce point de vue, voir Se moquant des Moqueries et des Résultats de ces Tests. par Oncle Bob

Par la façon dont, dans maven infaillible, vous pouvez toujours forkMode=toujours qui va de la fourche de la jvm pour chaque classe de test. Cela ne résout pas votre problème d'Eclipse.

OriginalL'auteur Matthew Farwell

Première : Mockito est à l'aide de CGLIB pour créer des objets fantaisie, et PowerMock est à l'aide de Javassist pour quelques autres trucs, comme le retrait de la finale de marqueurs, Powermock charge également des classes dans un nouveau chargeur de classe. CGLIB est connu pour manger de la Génération Permanente (juste google CGLIB PermGen pour trouver des résultats pertinents sur le sujet).

Ce n'est pas un droit de réponse car cela dépend des détails de votre projet :

1. Comme vous l'avez souligné, il est statique de la classe d'aide, je ne sais pas si détient les variables statiques et se moque ainsi, je ne connais pas les détails de votre code, donc c'est de la pure supposition, et les autres lecteurs qui sait vraiment mieux pourrait me corriger.

   Il pourrait être le chargeur de classe (et au moins certains de ses enfants) que chargé de cette classe statique peut être gardé en vie à travers des tests - il pourrait être à cause de la statique (qui vit dans le Classe royaume) ou en raison d'une référence quelque part - ce qui signifie que si le chargeur de classe vit encore (c'est à dire ne sont pas des déchets collectés) ses classes chargées, ne sont pas défaussées c'est à dire les classes, y compris le générés sont encore dans le PermGen.

2. Ces classes peuvent également être énorme en taille, si vous avez beaucoup de ces classes soient chargées cela pourrait être pertinent d'avoir plus de PermGen valeurs, surtout depuis Powermock besoin pour recharger les classes dans un nouveau chargeur de classe pour chacun des tests.

Encore une fois je ne connais pas les détails de votre projet, donc je suis juste deviner, mais votre génération permanente problème peut être provoqué soit par le point 1 ou le point 2, ou même les deux.

De toute façon de manière générale, je dirais que oui : le fait d'avoir une classe statique qui pourrait revenir statique se moquaient de l'objet ne ressemble à une mauvaise pratique ici, comme c'est généralement dans le code de production. S'il est mal conçu, il peut conduit à des chargeurs de classes de fuite (c'est méchant!).

Dans la pratique, je l'ai vu courir des centaines de tests (avec Mockito seulement) sans modification des paramètres de mémoire et sans voir le CGLIB procurations en cours de déchargement, et je ne suis pas en utilisant statique des trucs appart celles de la Mockito API.

Si vous êtes à l'aide de Sun/Oracle JVM vous pouvez essayer ces options pour suivre ce qui se passe :

-XX:+TraceClassLoading et -XX:+TraceClassUnloading ou -verbose:class

Espère que ça aide.

---

En dehors de la portée de cette question :

Personnellement, je n'aime pas utiliser d'utiliser Powermock de toute façon, je ne l'utilise que dans des cas limites par exemple pour les tests inmodifiable du code legacy. Powermock est trop intrusif à mon humble avis, c'est de reproduire pour chaque test d'un nouveau chargeur de classe pour effectuer ses actes (modification du bytecode), vous avez fortement annoter les classes de test pour être en mesure de s'en moquer, ...
À mon avis, pour habitude de développement de tous ces petits désagréments emporte sur l'avantage de la capacité à se moquer de finale. Même Johan l'auteur de Powermock, une fois m'a dit qu'il était recommanding Mockito la place et de garder Powermock pour un but précis.

Ne vous méprenez pas: Powermock est un fantastique morceau de la technologie, qui a vraiment aider quand vous avez à traiter avec la (mal) conçu le code de legs que vous ne pouvez pas modifier. Mais pas pour tous les jours developpement, surtout si entraînée TDD.

OriginalL'auteur Brice