Utilisation de MockitoJUnitRunner.class au lieu de SpringJUnit4ClassRunner.class

J’ai une question sur l’utilisation de SpringJUnit4ClassRunner . Pour les cas de Junits purs ou de tests unitaires, devrions-nous utiliser des annotations Spring, telles que @Autowired avec SpringJUnit4ClassRunner ou devrions-nous utiliser uniquement MockitoJUnitRunner place de l’annotation @RunWith en haut de la classe Test?

Je veux dire remplacer

 @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration({ "classpath:test-applicationContext.xml" })

avec juste

 @RunWith(MockitoJUnitRunner.class)

au sumt de la classe. Ça marche pour moi.

Dans Junits, nous ne faisons normalement aucun appel externe, tel qu’un appel à une firebase database ou à un autre service Web. Nous devons @Mock ces appels externes en utilisant des annotations @Mock sur ces objects de service. Et créez ensuite un object réel de la classe que nous testons et qui dépend de ces simulacres. Nous pouvons ensuite utiliser @InjectMocks sur l’object réel pour qu’il soit injecté avec les objects simulés.

Exemple Service-A-> Appels-> Service-B-> Appels-> Service-C

Tout en testant A, nous devrions simuler Service B et tout en testant Service-B, nous devrions simuler Service-C.

Un extrait de code

 @RunWith(MockitoJUnitRunner.class) public class TestServiceA { @Mock B mockObj; @InjectMocks A realObj; @Test public void testServiceA() { ..... ..... } }

Je pense donc que pour les cas de tests unitaires, nous n’avons pas besoin de compter sur le conteneur Spring pour nous fournir l’instance de la classe que nous testons.

S’il vous plaît donner vos suggestions.

Utilisation de SpringJUnit4ClassRunner.class au lieu de MockitoJUnitRunner.class

Si vous essayez simplement de tester une classe sans les dépendances, comme vous le décrivez, il n’y a aucun besoin de SpringJUnit4ClassRunner. Ce programme peut générer un contexte de ressort complet avec des objects (fictifs) que vous pouvez définir dans votre configuration de contexte d’application (test). Avec ce mécanisme, SpringJUnit4ClassRunner est beaucoup plus lent que le MockitoJUnitRunner standard.

SpringJUnit4ClassRunner est très puissant pour les tests d’intégration.

Par défaut, je commence par MockitoJUnitRunner et si j’atteins les limites de ce coureur, par exemple parce que je dois simuler des constructeurs, des méthodes statiques ou des variables privées, je passe à PowerMockJUnitRunner. Ceci est pour moi un dernier recours car il indique normalement que le code est «mauvais» et non écrit pour être testé. Les autres coureurs ne sont normalement pas nécessaires pour les tests unitaires isolés.