Comment se moquer de la persistance et de l'Entité avec Mockito et jUnit

J'essaie de trouver un moyen de tester mon entité à l'aide de Mockito;

C'est la simple méthode de test:

@Mock
private EntityManager em;

@Test
public void persistArticleWithValidArticleSetsArticleId() {
    Article article = new Article();
    em.persist(article);
    assertThat(article.getId(), is(not(0L)));
}

Comment puis-je mieux simuler le comportement que l'EntityManager change l'Id de 0L à dire 1L? Peut-être avec le moins de gêne dans la lisibilité.

Edit:
Quelques informations supplémentaires; en Dehors de test de la portée de l'EntityManager est produit par une application conteneur

Quelques informations supplémentaires; en Dehors de test de la portée de l'EntityManager est produit par une application conteneur (glassfish).
Vous pouvez simplement tester votre setId() et getId() méthodes pour la classe Article. Je pense qu'il n'est pas nécessaire de se moquer de l'EntityManager et dites-lui de définir l'id de l'article. Ce test sera plus adapté lorsque les tests unitaires EntityManager lui-même, lorsque vous voulez vérifier si l'id est généré et mis à l'entité que vous passez à persister.
Ce n'est pas le meilleur des cas, d'utiliser les moqueries de la bibliothèque. Regardez de plus près à votre test - ce que vous êtes en test ici est de vérifier si les moqueries de la bibliothèque fonctionne, au lieu de tester votre code. On se moque de sont utiles si vous avez besoin de se moquer/stub un comportement de composant interne de votre classe de test et vous savez comment ce composant se comporte dans des situations particulières.

OriginalL'auteur Patrick | 2014-11-15

  1. 5
    public class AssignIdToArticleAnswer implements Answer<Void> {

    private final Long id;

    public AssignIdToArticleAnswer(Long id) {
        this.id = id;
    }

    @Override
    public Void answer(InvocationOnMock invocation) throws Throwable {
        Article article = (Article) invocation.getArguments()[0];
        article.setId(id);
        return null;
    }
}

    Et puis

    doAnswer(new AssignIdToArticleAnswer(1L)).when(em).persist(any(Article.class));
    Il est intéressant de noter qu'avec cette solution, vous pouvez faire AssignIdToArticleAnswer intérieure de la classe de votre classe de test, puis utilisez la même doAnswer appel à plusieurs de vos méthodes de test. Vous pouvez même passer dans les différents identifiants, si cela vous convient de le faire. Ce qui rend cette solution plus polyvalente que ma solution, si vous êtes en train de faire quelque chose de plus que d'un seul test. +1.
    L'idée est bien la même, mais je préfère cette méthode pour la réutilisabilité et pour une meilleure lisibilité dans le test-méthode elle-même.
    pas une grosse affaire, mais pour personnalisée de la réponse, je voudrais créer statique usine méthode de retourner la réponse.

    OriginalL'auteur JB Nizet

  2. 9

    Vous pouvez utiliser un Mockito Answer pour cela. 

    doAnswer(new Answer<Object>(){
     @Override
     public Object answer(InvocationOnMock invocation){
        Article article = (Article) invocation.getArguments()[0];
        article.setId(1L);
        return null;
     }
  }).when(em).persist(any(Article.class));

    Cela dit Mockito que lorsque le persist méthode est appelée, le premier argument doit avoir son setId méthode invoquée.

    Mais si vous faites cela, je ne comprends pas quel est le but de ce test. Vous auriez vraiment juste des essais que le Mockito Answer mécanisme fonctionne, pas que le code de Article ou de EntityManager fonctionne correctement.

    Plus ou moins. J'ai été intéressé de voir que vous avez stocké la nouvelle carte d'identité dans un champ de la Answer objet. Je n'aurais pas pensé à faire cela, à moins que j'ai voulu réutiliser le Answer dans quelques endroits. Mais pourquoi avez-vous supprimer la vôtre? Je pense que c'est assez différent du mien qu'il valait la peine d'avoir à la fois ici. @JBNizet
    Je l'ai supprimé parce que j'étais fondamentalement la même que la vôtre, mais il est venu plus tard. J'ai récupéré depuis que vous avez pense que cela ajoute quelque chose. Dans ce cas précis, pour stocker l'id est inutile. En fait, j'ai emprunté le code que je me suis fait à l'aide de où la Réponse de la classe est en effet dans un haut-niveau de la classe, et peut être utilisé pour tout type d'entité, rendant réutilisables (et réutilisés).
    Merci pour cette réponse. La raison de ce test est plus pratique. Je suis à la recherche d'une façon de se moquer un vide-méthode qui exécute les lignes de code quand on l'appelle; Pour référence future.
    alors je vous recommande d'étudier la Mockito docs qui se rapportent à la Answer classe. C'est tout une région riche de la Mockito API, et Mockito a de nombreuses méthodes pour la création de Answer objets pour différents couramment utilisés opérations.
    Peut-être que vous pouvez poster qu'une réponse, avec un fragment de code, juste pour des raisons de visibilité, au lieu de l'enterrer dans les commentaires sous ma et JB réponses.

    OriginalL'auteur Dawood ibn Kareem

  3. 1

    similaire réponse que ci-dessus, mais avec des lambdas

       doAnswer((InvocationOnMock invocation) -> {
        Article article = (Article) invocation.getArguments()[0];
        article.setId(1L);
        return null;
    }).when(em).persist(any(Article.class));

    OriginalL'auteur gmode