Reprise du message précédent :
Mis a part ça, il fonctionne vraiment bien  
Je l'adopte pour la maison et le taf

je suis dessus en ce moment  
c'"est agréable  
bon l'écran est pas grand mais c'est le principe  
je vais pas grand chose pour le moment a part du chrome

je suis un mouton comme lamesse
j'ai acheté une surface a ma femme pour son examen d'instit
et comme lui, c'est moi qui joue avec

Je l'ai acheté pour moi, par contre.
Je suis un connard égoïste qui ne prête pas ses jouets et je l'assume

question test: comment vous faites pour unit tester une chaine de méthodes ?
Je peux bien sur tester que l'appel de A renvoit ce que je veux, mais vu que ça teste 80% du code de l'app derrière je trouve pas ça super unitaire...c'est normal ?
 
en gros : j'ai la méthode A qui appelle B qui appelle C qui appelle D qui renvoit un résultat qui remonte la chaine.
Exemple concret : mon parseur d'exif : je parse un jpeg qui appelle le parseur d'app marker qui appelle le parser de tiff qui appelle le parseur d'IFD qui renvoit une liste de tags.
 
un JPEG aura mettons 3 app markers avec des données, chaque app marker peut contenir 3-4 IFD, et chaque IFD contient 30-40 tags.
je peux tester que l'appel au jpeg parser renvoit genre 200 tags, que celui de l'app marker en renvoit 100, que celui de l'IFD en renvoit 25...c'est correct comme façon de tester ça ?
 

Je crois qu'on n'appelle plus ça un test unitaire surtout

Tu dois tester indépendamment chaque élément de ta chaîne. Après pour la classe qui les appelle, tu fais des mocks de chaque élément dont tu maitrises les réponses (ou tu passes un exif que tu connais bien, mais c'est plus un test unitaire parce qu'il teste pas seulement un comportement, mais celui de toute la chaine. Si ce test la fail, tu sais pas si c'est un des sous-éléments ou la classe testée qui a pété

I disagree. Si Jubi expose son parser complexe via une API très simple côté end-user, alors ses tests unitaires ce sera ça. Si dans son implémentation il a découpé bcp de choses mais que le code est dans des méthodes private par exemple, ce sera pas testable à ce niveau, sinon en cas de changement d'implémentation il devrait changer les tests avec.

Tu testes en unitaires les méthodes publiques et protected, car ces dernières sont exposées aux classes filles.

en l'occurence si, parce que comme je teste chaque maillon de la chaine, si un maillon pète son test va péter, tous les tests au dessus : poar ex si C pète, B et A vont péter aussi.

sinon j'ai entendu parler de cette histoire de mocking, mais j'ai pas forcément super bien compris le concept, j'ai pas compris ce qu'apportent les outils qui font du mock (jusqu'à maintenant je passe un objet complètement initialisé pour tester, comme mes objets sont assez plats, ça marche bien)

j'ai  lu à propos de cette philosophie du Unit testing, ça me parait assez intéressant (j'étais parti pour tout tester, mais tu changes une méthode tu pètes 5 tests)

en fait ce truc serait simple à unit tester si chaque sous élément de l'image était étanche, ie je peux lire les données et les passer en entier à la méthode suivante. Mais la spec TIFF dit que les données peuvent être n'importe où dans l'image, donc tu dois toujours avoir la main sur l'image pour aller lire dedans. Mais écrire ça vient de me donner une idée : je peux consider que le but de chaque fonction c'est de trouver les offset à passer à la suivante, et ça c'est testable

 
On peut justifier de tester des méthodes privées mais ce n'est effectivement pas l'idée en principe.
 
Concrètement ça a des conséquences pratiques très visibles : si une méthode est exposée, c'est qu'on a en tête des applications où un utilisateur pourrait vouloir l'utiliser, et donc des entrées valables pour ces méthodes. Ce n'est alors en principe pas compliqué de créer des cas tests triviaux qui couvrent toutes les fonctionnalités. Tandis que pour les méthodes privées, les objets en entrée/sortie sont souvent des cochonneries maison et l'effort nécessaire pour créer des cas tests rend le test pénible.
 
Dans ton cas ça me semble raisonnable de ne tester que l'interface.

Voila, en général, en faisant du unit testing tu améliores l'architecture du bouzin car tu vois tout de suite les couplages trop fort.
Faut pas hésiter à découper en + de classes aussi.

Bah non, ça ce sont des test d'intégration: il teste le fonctionnement de la librairie de bout en bout, c'est pas un test unitaire. Que la manière donc c'est implémenté rendent tester ce qu'il y a dans la boite possible ou non n'a aucune influence là dessus.

Fournir une interface simple, ça veut pas nécessairement dire que les pièces sont inaccessibles.

Et accessoirement, méthode privée != méthode pas testable, même en java-ish: http://www.artima.com/suiterunner/private.html

Le consensus c'est quand même qu'en général une méthode est privée pour de bonne raison et son test unitaire n'est pas pertinent. Il faut une bonne raison pour justifier l'effort supplémentaire lié à ce type de tests.

Ben non c'est un test unitaire. Si Jubi dans son test unitaire, il veut tester la méthode publique parse() de son parseur, ça peut bien faire appel à douze milles dépendances derrières, ça reste un test unitaire de la méthode parse(). C'est pas normalisé de toute façon la notion d'unité

C'est pas parce que c'est possible qu'il faut le faire (en PHP tu peux aussi tester des trucs que t'es pas censé tester, après c'est à toi de voir si tu veux le faire).
Perso, je déconseille fortement le testing des méthodes privées (conseil basé sur mon expérience personnelle ainsi que celles de mes équipes, sur plusieurs années de tests unitaires).

Jamais entendu cette raison être "cette méthode n'a pas besoin d'être testée". Il y a des raison pour qu'une méthode soit privée, il y a des raisons pour qu'une méthode soit testée, elles ne sont généralement pas liées.

Exemple simple: ton parser va probablement contenir une machine à état sous une forme ou une autre, l'état de la machine et les transitions n'ont aucune de faire partie de l'interface (bien au contraire) mais les bugs de SM étant un grand classique, tu vas probablement vouloir tester si tes conditions de transition sont pas foireuses.

Bah non.

C'est un test, c'est pas unitaire. Ça teste pas une unité, ça teste l'intégralité d'un système complexe.

Heureusement, c'est pas ce que j'ai dit

 
Qu'appelles tu un test d'intégration dans ce cas ?

C'est quoi une unité ?
(On peut jouer à "bah non", "bah si" si tu veux mais c'est pas ça qui va faire avancer le débat)

Ça dépend des architectures.

 
Ca dépend du type de langage,  OO -> classe / procedural -> function.

 
Ta classe A a une méthode B qui utilise un object de la classe C. Dans un test unitaire pour la classe A, tu te moques de l'implémentation (bugs ) de la classe C. L'idée c'est de remplacer toute utilisation de la classe C dans A par un object bidon, qui est lui censé retourner les bonnes valeurs.
 
Autrement dit, un bug dans C ne devrait pas faire échouer les tests unitaires de A.
 
Le danger dans tout ça, c'est de changer l'implémentation de C. Comme tu n'appelles jamais vraiment C, les tests unitaires de A pourraient continuer à passer bien que l'appli ne fonctionne plus. Tu écris dans ce cas des tests d'intégration, pour t'assurer que les différentes parties de ton programme fonctionnent ensemble comme prévu.

+1

merci à tous pour vos commentaires
 
j'ai finalement réécris les transitions pour que ce soit moins couplé...c'est un poil plus naif dans les transitions, mais j'ai trouvé plein de bugs que j'avais pas vu quand c'était tout lié.
 
j'ai aussi profité d'un truc très sympa en python : les @staticmethod et @classmethod peuvent être overridées, du coup tout ce qui n'a pas besoin d'être stateful est statique, du coup j'ai qu'une seule instance de chaque parser qui tourne
 
j'ai aussi creusé un peu py.test, et pretend

'Tain il m'a fallu 3 jours pour voir une tesla à Seattle.
 
Sinon, j'me fais chier

A Narbonne, j'ai dormi au novotel qui a un chargeur Tesla il y a 2 semaines. J'ai demandé au mec de la réception s'il voyait beaucoup de Tesla venir se charger, il m'a dit qu'il en voyait quelques unes. Je pense qu'il s'est foutu de ma gueule.

du coup j'en vois plein  

Premier résultat google "Should I test private methods" : http://stackoverflow.com/questions [...] ublic-ones

L'idée c'est qu'une méthode privée peut très bien avoir un comportement qui ne soit pas le comportement auquel s'attendrait un observateur externe, ou carrément changer de comportement en restant valide au cours d'un développement. C'est pour ça qu'elle est privée : parce qu'on ne veut pas que quelqu'un l'appelle en s'attendant à quelque chose de particulier. Et c'est précisément ce que fait un test unitaire.

Tu écris ta boite noire, plein de trucs privés
Tu testes ta boite noire de l'intérieur, pour t'assurer quand tu modifies le contenu de ta boite noire qu'elle ne pête pas ( tes tests externes ne permettront pas forcement de tout tester et ne te simplifieront pas la recherche d'un bug )

Je comprends votre position et c'est un débat récurrent quand on parle de tests, je fais juste remarquer que ce n'est pas le consensus.

Encore de la lecture : http://lassekoskela.com/thoughts/2 [...] e-methods/

c'est marrant que Jubi parle des tests de méthodes privées, j'ai eu la problématique en début de semaine également.
j'ai trouvé ce papier à ce sujet : http://agiletips.blogspot.fr/2008/ [...] -test.html

Il n'y a pas de consensus sur le réchauffement climatique ( dans le sens ou tu peux toujours trouver des gens qui n'y croient pas) , alors sur les tests ....

iLeak
 
Learn the internet, the hard way in one lesson.
 

il y a une photo avec du yaourt sur la figure... ah non en fait c'est pas du yaourt...

La philosophie de base des produits Apple, c'est que la plupart du temps tu laisses Apple décider du fonctionnement de tes appareils.
Si Apple te dit "stocke tout dans iCloud !", tu stockes tout dans iCloud.
Évidemment un power user ne va pas le faire, mais tu te doutes bien qu'Apple n'aurait pas eu le succès qu'il a eu s'il s'était cantonné aux power users.
Dès lors, comment reprocher à un utilisateur Apple d'avoir simplement fait confiance à Apple ?

T'as un point bonus pour la remarque sexiste

Pas moi
J'ai autre chose à faire de mon temps que de corriger des tests quand je me contente de changer l'implémentation de ma boîte noire et que le comportement externe est iso.

 
ouais, mais alors t'aura une mauvaise couverture de code, et ton chef qui a des objectifs là dessus ne serapas content

Parce qu'à un moment, faut se demander si c'est une bonne idée de laisser une entreprise privée décider de ce que tu dois faire ou pas de tes données persos ?

Oh tu sais, pas besoin d'avoir un vagin pour être une cruche en info. Je pourrais te parler d'un collègue qui s'est monté (dixit sa plaquette) une ferme de rendu à la pointe de la technologie...
 
... avec 2 quadros badgam poussiéreuses

 
Tu crois vraiment qu'elles (ou que les 9/10° des utilisateurs d'Apple ou Android) ont conscience de ce qu'elles font quand elles uploadent une photo sur ICloud, partagent un truc sur Facebook, G+ ou autre?
 

Bin maintenant y en a 2 de plus
Mais attention aussi : à la phrase "comment reprocher à un utilisateur Apple d'avoir fait confiance à Apple", moi je réponds "ba fallait réfléchir un peu". C'est ça qu'on peut leur reprocher. Je dis pas que tout le monde le fait, simplement qu'à un moment faut se poser les bonnes questions de ce qu'on doit faire avec ses données (très) privées, surtout quand on est une personne publique.

Excusez moi d'être bête, mais j'ai pas compris ce message. Y a une news que j'ai raté ?
 
(in other news: Visa, MasterCard, Amex et NFC, je crois que Apple va réussir à exploser le marché du paiement dématérialisé. Sauf en France, bien sûr, vu qu'on paye encore en chèque et en espèces).

En dehors de cloud, oude faire confiance à Apple...
Tu peux te faire voler ton téléphone, tu peux te faire pirater ton téléphone avec un virus ou un appli malicieuse... bon après tout le monde n'est pas forcement au courant...

Bin j'ai vu sur les topics infos insos que 2 célébrités bonnasses (Jennifer Lawrence et Bar Refaeli apparemment ?) s'étaient fait hacker leur compte iCloud sur lequel elles avaient mis des photos très intimes

EDIT : ah oui non, bien plus que ça :

Et donc Jennifer Lawrence et Rihanna.