L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

@sfui,

Tout à fait d'accord avec ton commentaire. En fait, mon billet visait plus à mettre en évidence la diversité des xunit patterns par rapport au trop simpliste et trop souvent entendu "test d'état vs test de comportement" mais, sur la fin, je me suis laissé aller à quelques propos hors sujet par rapport à mon but initial.

Pour ce qui est du changement de code du thermomètre qui fait planter le test sur le comportement, la question sous-jacente, c'est "quel est le contrat représenté par la méthode 'écris' ?"
Est-ce un appel qui permet de connaitre la dernière valeur observée ?
Est-ce un appel qui permet de connaitre tous les changements d'état de la variable observée ?
Est-ce un appel qui permet de connaitre toutes les observations ?

La réponse dépend du PO, mais pas forcément de manière directe. Si, dans la réalité, l'écran est toujours un simple afficheur d'une valeur unique alors le contrat pourrait être renommé en "ecris_la_derniere_valeur_observee" et l'ambiguité serait ainsi levée. Si l'écran est un traceur de graphe des diverses valeurs observées à intervalle régulier alors le choix sera probablement différent.

@Guillaume

Précisons tout d'abord que ce ne sont pas mes définitions de mock et spy mais celles de Meszaros. Ca fait quand même une différence.
Ces deux patterns sont effectivement très proches car ils portent tous deux sur la vérification des sorties indirectes du système à tester
La principale différence de concept que j'observe entre ces deux patterns c'est que l'un vérifie directement le comportement, l'autre se focalise sur certaines (choisies par le testeur) conséquences de ce comportement.
Sur http://xunitpatterns.com/, Meszaros va bien plus loin et explique les différences d'utilisation entre les deux patterns. Je n'y reviendrai pas.

En ce qui concerne les 3 niveaux de tests de JB Rainsberger, je suis un peu sceptique sur la systématisation de cet extrémisme. D'après mon expérience, qui ne vaut pas plus que ce qu'elle vaut, les objets ayant un état intéressant et les objets ayant un comportement intéressant forment deux ensembles plus ou moins distincts.

Quant à la différence entre tests de contrat et tests de collaboration, je ne la comprends pas. Je ne vois pas ça comme 2 éléments ayant une nature distincte, c'est plutôt un détail d'implémentation joue sur l'initiation de la séquence de test :-)

@Guillaume,

Et pourtant, malgré leur cousinage (leurs vérifications portent sur les sorties indirectes) spy et mock ne vérifient pas la même chose.
Je vais essayer une analogie.
Le spy, c'est le stagiaire dont on se sert pour faire des taches demandant peu de prise de responsabilité. Il ne se souvient pas forcément de tout ce qui se dit mais il fait remonter les infos nécessaires à son patron (le test) pour que celui-ci prenne la décision de vérification adéquate en utilisant des données que le spy n'a pas toujours en sa possession.
Le mock, c'est quelq'un de plus expérimenté. Le patron lui fait confiance pour faire des vérifications. On aime bien l'utiliser car il est rapidement opérationnel à moindre coût mais si la situation se complique par rapport à ce qu'il sait faire vite et bien, le patron préfèrera faire les choses lui même à l'aide d'un spy.

Pour ce qui est des "tests de contrat et de collaboration", je suis tout à fait d'accord avec la nécessité d'avoir 2 tests, un de chaque côté de "ecris". Mais dans les 2 cas j'appelle ça "test de contrat". Je ne vois aucune raison pour donner 2 noms différents. L'utilisation du sens des dépendances n'apporte, à mon sens, aucune information utile à la définition du scénario de test.
Dans l'état actuel, le thermomètre dépend d'un écran et on met en place le système en injectant un écran dans le thermomètre. Si je comprends bien ton raisonnement (et celui de jbrain), c'est ce qui permet de dire que l'écran ne fait qu'exposer un contrat et que le thermomètre s'attend à travailler avec un collaborateur.
Donc, dans le cas où je déciderais de modifier ma conception pour injecter le thermomètre dans l'écran en utilisant, par exemple, un système d'évènements levés par le thermomètre quand il y a qqe chose à afficher et auquel on abonnerait l'écran, j'aurais exactement le même scénario mais, en tant que thermomètre, mon test de collaboration avec un écran se transformerait en test de contrat où j'expose des évènements.
Cette distinction artificielle ne m'apporte rien. Quel que soit le sens des dépendances, l'information circule du thermomètre vers l'écran et c'est la seule chose qui m'importe vraiment pour mettre en place mes tests.

1/ on veut avoir un vocabulaire précis pour identifier tous les types de tests nécessaires sur un objet

On peut inventer toutes sortes de typologies, ça ne les rend pas utiles pour autant

2/ on ne teste pas la même chose dans ces deux types de test

Dans les 2 cas on teste le comportement d'un SUT face à son environnement

3/ ils n'utilisent pas les mêmes instruments de test (typiquement un test de collaboration va + utiliser un mock).

Non. C'est faux.

Ce que montre fort justement Meszaros, c'est que l'important dans un test de comportement, ce sont les sorties indirectes et que le choix de mise en oeuvre du test dépend donc principalement du sens d'écoulement des données.

Qu'ils soient dans un test de "contrat" ou de "collaboration", le stub est toujours du côté de l'entrée des données et le mock ou le spy toujours du côté de la sortie.

Dans le billet, on test sur le thermomètre une soi-disante "collaboration" avec l'écran et l'écran est un mock ou un spy. Si j'inverse la dépendance, on teste un soi-disant "contrat" pour le thermomètre mais l'écran est toujours un mock ou un spy parce que c'est un contrat de réception de données.

La preuve en images (et en plus ça me fait pratiquer mon Ruby).

J'inverse la dépendance en définissant un thermomètre"observable" :

class ThermometreObservable

  include Observable

  def initialize(capteur)
    @capteur = capteur
    @temperature_maximale = -273.15
  end

  def affiche_temperature_maximale
    temperature_courante = @capteur.lis_temperature_courante
    if temperature_courante > @temperature_maximale
      @temperature_maximale = temperature_courante
    end
    changed
    notify_observers(@temperature_maximale)
  end

end

Je modifie le test avec un mock en conséquence tout en gardant mon ecran comme mock :

  def test_avec_un_stub_et_un_mock
    capteur = flexmock("capteur")
    capteur.should_receive(:lis_temperature_courante).and_return(21, 18, 25)

    ecran = flexmock("ecran")
    ecran.should_receive(:update).with(21).times(2).should_receive(:update).with(25).once.ordered

    thermometre = ThermometreObservable.new(capteur)
    thermometre.add_observer(ecran)
    3.times { thermometre.affiche_temperature_maximale }
  end

Ou je peux aussi faire avec un spy :

  def test_avec_un_stub_et_un_spy
    capteur = flexmock("capteur")
    capteur.should_receive(:lis_temperature_courante).and_return(21, 18, 25)

    ecran = Object.new
    def ecran.update(texte)
      @texte = texte
    end
    def ecran.affiche
      @texte
    end

    thermometre = ThermometreObservable.new(capteur)
    thermometre.add_observer(ecran)
    thermometre.affiche_temperature_maximale
    assert_equal( 21, ecran.affiche )
    thermometre.affiche_temperature_maximale
    assert_equal( 21, ecran.affiche )
    thermometre.affiche_temperature_maximale
    assert_equal( 25, ecran.affiche )
  end