Mock stub et testing


#1

Bonjour

Je débute dans les tests avec rails.

J ai commencé à regarder un peu les livres et les exemples scaffold de
rspec.

Mais je m’embrouille dans la différence entre stub et mock et dans les
bonnes practices.

Quelqu’un aurait une lecture à me conseiller ou pourrais un peu parler
des best pratices ? !

Merci beaucoup par avance !!

Antoine


#2

Le 13 avril 2009 12:52, Antoine a écrit :

Mais je m’embrouille dans la différence entre stub et mock
et dans les bonnes practices.

L’un des articles de référence est celui de Martin F. :

“Mocks Aren’t Stubs”
http://martinfowler.com/articles/mocksArentStubs.html

Concernant les best practices, les avis peuvent être
partagés, les mocks objects peuvent être
conseillésou non selon la personne qui te répond.

– Jean-François;


http://twitter.com/underflow_


#3

J ai lu l article j avoue que j ai pas tout compris !!

Y a t il d autres liens en francais peut etre plus simple pour
expliquer les diférrentes approches ??


#4

Mais je m’embrouille dans la diff�rence entre stub et mock et dans les
bonnes practices.

  1. Un stub c’est simplement une simulation de méthode (ou de classe)
    avec une réponse préfabriquée qui est souvent utilisé pour s’affranchir
    d’un service externe ou simplement pour isoler une portion de ton
    application.

Exemple:
ton application doit se connecter à google maps pour fonctionner, mais
durant tes tests tu ne veux évidemment pas y accéder (trop lent,
firewall qui bloque, service momentanément indisponible, etc), donc tu
simules une réponse de google maps et ça permet de feinter ton
application pour qu’elle puisse fonctionner comme si elle communiquait
vraiment avec google maps.

  1. Un mock c’est un test en lui-même, plus exactement une
    assertion/expectation ou une ‘attente’ / ‘espérance’ en français. Donc
    tu dis dans ton test qu’une certaine classe ou méthode devrait être
    appellée si tout va bien pendant le déroulement d’un test. Tu peux y
    ajouter avec quels arguments histoire d’être un peu plus précis, et
    rajouter une réponse préfabriquée, un stub donc. Le stub est optionnel
    mais dans la plupart des cas il est nécessaire. Donc mock = test + stub

Ca permet de détecter les erreurs quand tu changes ton api en oubliant
d’éditer les appels des méthodes.

En espérant éclairer ta lanterne.


Formations vidéos sur http://www.digiprof.fr


#5

Ca permet de détecter les erreurs quand tu changes ton api en oubliant
d’éditer les appels des méthodes.

Après un petit problème de best-practice c’est qu’utiliser un mock va
casser la règle du ‘1 assertion per test’ puisque le mock rajoute une
assertion. A médtier si vraiment le mock est nécessaire ou si juste
l’évalutation de la méthode testée est ce qui compte.


Formations vidéos sur http://www.digiprof.fr