Quand et pourquoi utiliser Mocking lors du test des EJB

Question

comme cela apparaît dans ma question, je suis confus quant à savoir quand et pourquoi utiliser des objets fictifs lors du test des ejbs. J'utilise JUnit simple et je trouve que ça marche, mais je sais que ce n'est pas toute l'histoire.

Exemple:

@Stateless(name = "MyService") 
public class MyBean extends BaseBean implements MyService 
{ 
    public MyBean() 
    { 
    } 

    public List<Category> getAllMainCategories() 
    { 
     //Category.findAll is a named query defined in Category entity 
     return (List<Category>) em.createNamedQuery("Category.findAll").getResultList(); 
    } 
} 

Et voici la classe de test:

public class MyServiceTest 
{ 

    MyService service; 

    @Before 
    public void setUp() throws Exception 
    { 
     Context context = new InitialContext(); 
     service = (MyService) context.lookup("MyService"); 
    } 

    @Test 
    public void getAllMainCategories() throws Exception 
    { 
     assertNotNull(service); 
     assertTrue(service.getAllMainCategories().size() > 0); 
    } 

} 

Comme vous le voyez, je suis en train de faire des tests unitaires pour les haricots de session sans avoir besoin d'objets fantaisie ... donc est c'est entièrement vrai, ou je manque de quelque chose?

Answer 1

Vous vous moquez lorsque vous voulez tester quelque chose qui a une dépendance isolée. Par exemple, si un service utilise un DAO, lorsque vous testez le service unitaire, vous vous moquez du DAO pour être certain que les échecs de test se produisent en raison du code de service et non du code DAO. Pour le dire autrement, si vous ne vous moquez pas du DAO et que votre test de service échoue, vous devez savoir si le test a échoué parce que l'appel DAO a échoué ou à cause du code de service. De plus, l'utilisation de simulacres simplifie le test, car vous disposez d'une quantité constante de configuration de test. Comme le nombre de dépendances augmente, il peut être difficile de satisfaire toutes les exigences dont les dépendances ont besoin. Par opposition à l'utilisation de simulacres, où la seule dépendance que vous devez satisfaire est la mise en place des attentes dans votre cadre factice.

Answer 2

Vous pouvez jeter un oeil here (blog Martin Fowler) pour des informations liées à Mocks.

Mock sont utilisés lorsque vous souhaitez tester un code qui a une dépendance aux effets secondaires. Les appels à certaines bibliothèques de services, comme DAO comme le suggère une autre affiche, sont des utilisations typiques. Cependant, l'utilisation de simulacres n'est jamais obligatoire. Dans le cas DAO, une alternative pourrait être de fournir à votre classe testée un objet wrapper DAO. Dans le cas de test, vous devez fournir un autre type d'objet encapsuleur DAO qui génère des résultats contrôlés. Cette méthode pour éviter les faux-semblants est appelée "injection de dépendance" et donne le même avantage que les simulacres (en réalité, c'est la même chose que d'utiliser des bibliothèques simulées, mais faites "à la main"). Mais dans certains cas, l'utilisation de l'injection de dépendances à la place de la bibliothèque Mocks est un peu difficile (vous devez définir un objet wrapper que vous pouvez dériver au lieu d'utiliser le standard).

Personnellement, je n'aime pas beaucoup les Mocks et j'essaie d'éviter de les utiliser lorsque cela est possible. Les raisons pour lesquelles je ne les aime pas sont parce qu'elles conduisent facilement à des tests qui ne manquent pas quand le comportement de l'API externe change, oui c'est de vrais tests unitaires, mais trop solides à mon goût. Un autre point est parce que, en utilisant des simulacres, nous avons tendance à tester le comportement interne de ce que je pense devrait être une boîte noire, mais Mocks ont aussi de grands fans.