// notre simulacre est prêt à être utilisé
 // étape 1 : on introduit la doublure
 MessagerieUtilisateur messagerie = new MessagerieUtilisateur(mockIdentification);
 // étape 2 : on lance le traitement
 messagerie.lireMessages("toto", "mdp");
 messagerie.lireMessages("toto", "mauvais_mot_de_passe");
 // étape 3 : Le code a été exécuté, voyons ce que rapporte l'espion
 // vérifions que la méthode identifier() a bien été appelée exactement une fois avec ces paramètres
 Mockito.verify(mockIdentification, times(1)).identifier("toto", "mdp");
 // et exactement une fois avec ces paramètres
 Mockito.verify(mockIdentification, times(1)).identifier("toto", "mauvais_mot_de_passe");
Mockito propose bien sûr d'autres utilisation de codice_7, permet de vérifier l'ordre dans lequel les méthodes ont été appelées etc. Pour voir toutes les possibilités, il faut se référer à la documentation de Mockito.
Les substituts (ou « fake »).
Un substitut est une doublure écrite à la main qui implémente le comportement attendu d'une classe mais de façon plus simple. Contrairement au bouchon qui est écrit spécifiquement pour un test, le substitut a vocation à être suffisamment générique pour être utilisé dans plusieurs tests. Il est donc plus compliqué à écrire que le bouchon mais à l'avantage d'être réutilisable, le temps supplémentaire passé à écrire cette doublure peut être rentabilisé si elle est réutilisée dans d'autres tests.
Un exemple.
Revenons à notre premier exemple, celui du bouchon. Notre test est très court, supposons que nous avons d'autres tests à mener sur notre classe codice_8. Par exemple, on voudrait tester le comportement de la classe avec plusieurs utilisateurs différents, et vérifier que les messages sont bien stockés. Nous avons la possibilités de créer d'autres bouchons pour chacun de ces tests, mais essayons plutôt d'écrire un substitut qui pourra servir dans chaque test.
/** doublure de la classe IdentificationUtilisateur
 * c'est un substitut qui est utilisé dans MessagerieUtilisateurTest
public class IdentificationUtilisateurStub {
 /** les comptes de tous les utilisateurs, identifiants et mot de passes associés */
 Map<String, String> comptes = new HashMap<String, String>();
 /** vrai si le compte a été ajouté et le mot de passe est valide */
 @Override
 boolean identifier(String identifiant, String motDePasse) {
 boolean result = false;
 if (comptes.containsKey(identifiant)) {
 if (comptes.get(identifiant).equals(motDePasse)) {
 result = true;
 return result;
 /** ajoute un compte à l'ensemble des comptes valides */
 public void ajouterCompte(String identifiant, String motDePasse) {
 comptes.put(identifiant, motDePasse);
Ce substitut devrait nous permettre d'écrire les différents tests évoqués. Il suffira, au début du test, d'ajouter zéro, un ou plusieurs comptes selon le besoin.
Les fantômes (ou « dummy »).
Il s'agit du type de doublure le plus simple, il s'agit simplement d'un objet qui ne fait rien puisqu'on sait que, de toute façon, dans la méthode testée, il n'est pas utilisé. Il y a plusieurs façons simples de créer un fantôme :
Comment utiliser les doublures.
Finalement, reprenons la totalité des cas évoqués et voyons comment les doublures peuvent nous aider.
Quoiqu'il en soit, il faut toujours essayer d'utiliser les doublures avec parcimonie. Elles donnent l'illusion de tester l'application alors qu'en fait, on teste des coquilles vides qui ne permettent finalement pas de présager du comportement final de l'application, quand celle-ci utilisera intégralement les implémentations en lieu et place des doublures. Abandonner l'idée d'utiliser une doublure si son code devient trop complexe par rapport à la complexité du test qu'elle est censée permettre.
Tester une classe abstraite.
L'objectif est de tester les méthodes concrètes d'une classe non-instantiables. Supposons l'existence d'une classe A, abstraite, et de B et C des implémentations concrètes. Plusieurs possibilités :
Mockito permet cela grâce à son support de mock "réels" partiels (c'est à dire des simulacres qui peuvent adopter le vrai comportement de la classe simulée) :
 @Test
 public testUneMethodeConcrete() {
 // préparation des données en entrées pour le test
 int a = 1;
 A mock = Mockito.mock(A.class);
 Mockito.when(mock.uneMethodeConcrete(a)).thenCallRealMethod();
 // assertions...
 assertEquals(2, mock.uneMethodeConcrete(a));
Implications de l'utilisation de doublures.
Limites des doublures.
Dans certains codes, il sera difficile de substituer un objet par sa doublure. C'est particulièrement le cas si, par exemple, on souhaite remplacer un objet qui est un attribut privé de la classe, qu'il est affecté dès l'initialisation de la classe par la classe elle-même et qu'on a pas de possibilité de le modifier depuis l'extérieur.
/* comment remplacer attributPrive par sa doublure pour tester
 * methode() ? Dans ce cas, ce n'est pas possible.
public class ClasseTestee {
 private final UneClasseQuelconque attributPrive = new UneClasseQuelconque();
 public methode() {
 // code qui fait appel a attributPrive
La manière dont cette classe est écrite limite l'utilisation de doublures, elle réduit la testabilité du code et montre que les possibilités d'utilisation de doublures peuvent être réduites voire nulles. Nous verrons dans le chapitre « Tests et conception » comment éviter ce genre d'écueil.

Photographie/Fabricants/Canon/Canon PowerShot SX120 IS

Photographie/Fabricants/Panasonic/Panasonic Lumix DMC-LX5

Photographie/Fabricants/Samsung/Samsung NX 10

Mécanique, enseignée via l'Histoire des Sciences/La chute ralentie sur plan incliné (suite)