[JAVA] [Mockito] 3.2.4 → Après la mise à jour vers 3.3.x, une erreur s'est produite (bien que Iketenai)

Après la mise à jour de Mockito 3.2.4 vers 3.3.x (3.3.3) ... Le code qui définit le stub est-il redondant? J'ai eu une erreur à cause de ça.

De quel genre de code s'agissait-il?

C'était un tel code.

when(rs.getInt("column")).thenReturn(100);		
assertEquals(Integer.valueOf(100), TYPE_HANDLER.getResult(rs, "column"));
		
when(rs.getInt("column")).thenReturn(0);
assertEquals(Integer.valueOf(0), TYPE_HANDLER.getResult(rs, "column"));

Quel genre d'erreur avez-vous obtenu?

Telle est l'erreur.

org.mockito.exceptions.misusing.UnnecessaryStubbingException: 
Unnecessary stubbings detected.
Clean & maintainable test code requires zero unnecessary code.
There are 1 unnecessary stubbing (click to navigate to relevant line of code):
  1. -> at org.apache.ibatis.type.YearTypeHandlerTest.shouldGetResultFromResultSetByName(YearTypeHandlerTest.java:44)
Please remove unnecessary stubbings or use 'lenient' strictness. More info: javadoc for UnnecessaryStubbingException class.

Qu'est-ce qui est cool?

Apparemment ... thenReturn semble être cool, et l'erreur a disparu en faisant ce qui suit.

when(rs.getInt("column")).thenReturn(100, 0); //Consolidez en un seul endroit! !!
assertEquals(Integer.valueOf(100), TYPE_HANDLER.getResult(rs, "column"));
assertEquals(Integer.valueOf(0), TYPE_HANDLER.getResult(rs, "column"));

Eh bien ... c'est comme ça.

Dois-je corriger le code?

Si vous n'avez pas une intention claire, vous devez essentiellement corriger le code, mais vous pouvez supprimer cette erreur en le mettant en mode "indulgent" comme décrit dans le message d'erreur. Voici quelques moyens de le dissuader.

NOTE:

C'est un élément dissuasif que j'ai trouvé dans une recherche rapide, il peut donc y avoir d'autres moyens plus efficaces! !!

Utilisation de l'attribut «clément» de «@ Mock»

Lorsqu'un objet fictif est créé à l'aide d'une annotation, il peut être supprimé en spécifiant l'attribut de l'annotation.

// @Mock
@Mock(lenient = true)
protected ResultSet rs;

Utilisez MockSettings # lenient ()

Si un objet fictif est créé à l'aide de la méthode Mockito # mock, il peut être supprimé en spécifiant l'option de la méthode.

// ResultSet rs = mock(ResultSet.class);
ResultSet rs = mock(ResultSet.class, withSettings().lenient());
when(rs.getInt("column")).thenReturn(INSTANT.getValue());
assertEquals(INSTANT, TYPE_HANDLER.getResult(rs, "column"));
when(rs.getInt("column")).thenReturn(0);
assertEquals(Year.of(0), TYPE_HANDLER.getResult(rs, "column"));

Utilisation de Mockito.lenient ()

Vous pouvez utiliser Mockito.lenient () pour le supprimer, mais il vaut mieux le réparer que de le supprimer de cette façon.

// when(rs.getInt("column")).thenReturn(100);
lenient().when(rs.getInt("column")).thenReturn(100);
// ...

JUnit 5: Utilisation de l'attribut strictness de @ MockitoSettings

Si vous utilisez JUnit 5 (MockitoExtension), vous pouvez le supprimer en spécifiant l'attribut de l'annotation @ MockitoSettings. Ce paramètre semble s'appliquer à la partie qui utilise la méthode Mockito # mock.

@MockitoSettings(strictness = Strictness.LENIENT) //Ajoute ça
@ExtendWith(MockitoExtension.class)
abstract class BaseTypeHandlerTest {
  // ...
  @Mock
  protected PreparedStatement ps;
  // ...
}

NOTE:

Bien que cela ne soit pas mentionné dans cette entrée, il semble que JUnit 4 ait des options similaires.

Résumé

Mickito est une bibliothèque très utile pour préparer les hypothèses pour les tests unitaires, mais si vous ne gardez pas leur code propre, cela a tendance à ressembler à "que faites-vous?" Alors ... je suis reconnaissant pour ce genre de mécanisme de contrôle (parfois je ne sais pas comment le réparer ...: sweat_smile :). Cependant, le contenu du rapport de la bibliothèque n'est pas toujours correct, c'est donc une bonne idée de vérifier le contenu et le code du rapport, et d'envisager d'utiliser le mode "indulgent" si nécessaire.