2010-09-11 15 views
0
package com.fitaxis.test; 

import java.sql.SQLException; 

import org.junit.Assert; 
import org.junit.Test; 
import org.mockito.Mockito; 
import org.mockito.invocation.InvocationOnMock; 
import org.mockito.stubbing.Answer; 

import static org.mockito.Mockito.*; 

import com.fitaxis.leaderboard.LeaderBoard; 

public class LeaderBoardTests { 


@Test 
public void TestThatDataIsSavedToTheDatabase() 
{ 
    LeaderBoard leaderBoard = mock(LeaderBoard.class); 
    //doNothing().doThrow(new RuntimeException()).when(leaderBoard).saveData(); 

    when(leaderBoard.saveData()).thenReturn(true); 

    boolean res = leaderBoard.saveData(); 

    verify(leaderBoard).saveData(); 

    Assert.assertTrue(res); 
} 

} 

Je l'ai utilisé Mockito pour se moquer d'une classe, mais quand j'utilise la couverture de code, il ne détecte pas que la méthode comme cela a été appelé. Est-ce que je fais quelque chose de mal? S'il vous plaît aider!Mockito Laissez-passer, mais la couverture du code encore faible

+0

Je ne comprends pas la question. Une exception est-elle levée? Qu'est-ce que cela signifie "la couverture de code encore faible" - vérifiez-vous avec un outil externe? laquelle est-ce? Cobertura? – Bozho

+0

J'ai utilisé EclEmma. Normalement, quand je me moque de quelque chose et que j'utilise un outil comme NCover, il montre la méthode invoquée, je me demande si je fais quelque chose de mal c'est tout. – ferronrsmith

Répondre

7

Il semble que vous vous moquiez du seul appel que vous apportez au code de production.

En d'autres termes, votre test dit:

  • Quand j'appelle saveData(), faux résultat pour revenir vrai
  • appeler maintenant saveData() - youpi, le résultat était vrai!

Aucun de votre code de production n'est un appel du tout, pour autant que je puisse voir. Le point de se moquer est de simuler les dépendances de votre classe de production, ou (parfois, si je préfère ne pas) de se moquer de certaines méthodes de votre classe de production que le code que vous êtes en train de tester appellera.

Vous devriez probablement se moquer des dépendances de Leaderboard plutôt que Leaderboard lui-même. Si vous devez maquette en saveData(), vous devriez tester les méthodes appelsaveData() ... vérifier qu'ils économisent les bonnes données, qu'ils agissent correctement lorsque saveData() renvoie false, etc.

+0

Vous avez raison, mais j'ai fait la même chose avec NUnit et RhinoMocks et NCover l'a détecté comme un appel. Je me demande si je devrais utiliser un soupir d'interface. – ferronrsmith

+0

Semble que je vais devoir faire un test d'intégration, j'essayais d'éviter de frapper la DB pour le test, mais je me moque de l'enregistrer dans la base de données, mais il semble que j'obtienne une couverture de code. Merci pour l'aide tous :) – ferronrsmith

+4

@ferronrsmith: Vous semblez manquer la poussée de mon message: ** votre test est inutile **. Il ne teste * * aucun code. Qu'attendez-vous qu'il fasse? Vous ne devriez pas écrire des tests pour obtenir une couverture de code; vous devriez les écrire pour exercer votre code. Le test que vous avez présenté ne le fait pas. Par tous les moyens se moquent de la partie de sauvegarde, mais ensuite appeler un autre code qui à son tour appelle 'saveData()'. Appeler simplement 'saveData()' directement est inutile. (Je suis intrigué quant à la façon dont vous avez utilisé NUnit et RhinoMocks quand il s'agit de code Java, btw ... Vous n'avez clairement pas testé le même code. –

4

si je comprends votre question correctement:

parce que vous vous moquez de LeaderBoard. Cela signifie que vous ne le testez pas. Si vous voulez tester LeaderBoard, vous devez tester la classe réelle et non la maquette. Supposons que vous vouliez tester la classe A, mais que cette classe dépend de B et B est un peu difficile à instancier dans l'environnement de test (pour une raison quelconque). Dans ce cas, vous pouvez mocker B.

mais voici votre cas où vous vous moquez de la classe A elle-même. Cela signifie que vous ne testez rien.