Discussion :

[amira]

Bonjour,

Je me pose une question. Faire des tests trop avanc�s, j'entends par l�, v�rifier que tous les mocks sont bien appel�s, un certain nombre de fois, avec des captor, etc. (exemple :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
when(myMock.maFonction(captor)).thenReturn(...); 
verify(myMock, times(4).maFonction(captor)); 
assertEquals(captor.getValue(), moObjet);

)

Est-ce une mauvaise pratique ? Souvent, ce genre de tests ne sont qu'une "duplication" du code de production et quand ce dernier change, on est souvent oblig�s de changer le code de tests lui-m�me ce qui fait perdre de l'int�r�t au process. En somme, est-ce qu'�crire des tests trop pouss�s n'est-il pas contreproductif?

Je n'arrive pas vraiment � trouver de documentation sur �a, si vous avez une id�e

[gervais.b]

Bonjour,

Vous ne trouverez pas de "documentation" � proprement parler, c'est de l'appr�ciation.

// ! Avis personnel
Je ne dirais pas que des tests trop pouss�s sont mauvais. Mais plut�t qu'il faut tester ce qui est utile.
Comem vous le dites, vos tests sont de la duplication de la logique. Est-ce vraiment important de savoir que votre m�thode va appeler 4 fois une autre m�thode ? Je ne crois pas. Ce qui est iportant c'est de v�rifier que la sortie soit correcte.

Imaginons que `isBirthDay` doive retourner retourner true ou false ou lancer une exception si la date de naissance est invalide.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
  // Pseudo code
  boolean isBirthDay(Person p) {
     validator.validateOrThrow(p.getBirthDay());
     return today().equals(p.getBirthDay())
  }

On � pas besoin de v�rifier que `validator` ou `p.getBirthDay()` soient appel�es. Ce que l'on veut tester c'est les entr�es et sorties :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
  // Pseudo code
  must_return_true_when_birth_date_is_today() {
    Person p = new Person(dateOfToday())
    assertTrue(isBirthDay(p))
  }
 
  must_return_false_when_birth_date_is_not_today() {
    Person p = new Person(notToday())
    assertTrue(isBirthDay(p))
  }
 
  must_fail_when_birth_day_is_absent() {
    Person p = new Person("")
    assertFailWithException(isBirthDay(p))
  }

Le probl�me avec votre exemple est que, si vous changez la fa�on de valider la date, il faudra changer vos tests. C'est pourtaht l'objectif inverse qui est vis�, id�alement vous devriez pouvoir changer l'impl�mentation sans modifier les tests.

[amira]

Merci pour ta r�ponse. Je comprends ce que tu veux dire