Reprise du message précédent :

Une variante de ce que je viens d'écrire juste au-dessus, avec foo comme décodeur et et la fonction qui crée x en encodeur, quoi, si foo et l'autre fonction sont à des interfaces.

Beaucoup de tests unitaires (ne testent qu'une seule fonction pure, dont on contrôle complètement l'environnement y intégrant des mocks, typiquement), moins de tests fonctionnels, et une poignée de tests d'intégration.

Write tests. Not too many. Mostly integration.

Enfin la rente est complètement symbolique et ne rentabilise pas l'investissement initial (6,10€/an pour le chevalier et 9,15€/an pour l'officier en 2010).

ok, je vois.
Perso ma "pyramide" se limite aux tests U et aux tests d'intégration.

Ah oui voilà, merci pour les ref, je savais bien qu'on avait écrit contre la pyramide des tests depuis...
 
Au fond j'ai rien contre la pyramide des tests, je pense qu'elle est toujours valable ; mais c'est une propriété émergente, certainement pas un objectif ou un argument quand on est pas d'accord sur quel test faire.

De l'autre côté, quand t'es sur une appli Web où pour chaque classe de tests tu te tapes du spin up de db avec des fixtures alors que tu es juste en train de t'assurer que le contrat renvoyé au client est OK dans tes différents scénarios, ça fait vraiment chier.
Oui pour les tests d'intégration mais si c'est bien découplé, tu n'as pas toujours besoin d'avoir à te taper la persistence et tout le bordel derrière.

Souvent on se retrouve dans des tests d'intégration parce que les détails d'implémentation vont trop loin (pas assez découplé) et qu'en tests unitaires c'est l'orgie.

Bon après j'ai découvert hier qu'un gars de mon équipe ne savait pas qu'on pouvait "patcher" des appels pour se concentrer sur le scénario essentiel (ça évite des gros mocks bien dégueulasses inmaintenables)

Moi je pense qu'elle l'est de moins en moins.
 
Martin Fowler le dit lui même: https://martinfowler.com/bliki/TestPyramid.html
 

 
Il me semble qu'en 2022 cela n'est plus vrai, grace aux évolutions du langage, des frameworks et du tooling.

Attention à ne pas être trop précis, tu vas avoir la guilde des software crafts(wo)men qui te tombe dessus si tu dis autre chose que "ça dépend" ou "ni trop, ni trop peu"

Je fais parti de la guilde des SC justement pour pouvoir être précis

Property based testing enters the chat.

Bon d'un côté je vois pas a priori ce qui empêche un test unitaire avec des valeurs cohérentes de x, de l'autre si c'est appelé plus haut, autant faire d'une pierre deux coups en effet.

Perso pour nos services web j'écris quasiment que des tests point à point.

J'étais en train de faire un JDD pour un store locator,

et j'avais juste dans mon exemple "city" et "country",
Et j'avais besoin des latitudes et longitudes, j'ai créé 2, 3 use case juste avec avant des lat,lon

Et après j'ai regardé et Github copilot me proposait les latitudes et longitudes des villes que je mettais, mêmes des bleds pommés :

J'adore ça aussi les suites de tests unitaires ultra rapide. C'est juste pas un objectif en soit, il faut qu'ils servent à quelque chose.

C'est beau, sinon pour éviter d'écrire ça a la main, tu peux utiliser des tooling comme faker.js (et équivalents sur autres langages).

Exact

Ici c'est toujours vrai, en C++ en tout cas les tests pas unitaires sont lents et gourmands en ressources.

Harko porn
https://haroohie.club/blog/2022-10- [...] mpression/

Du coup ce que j'en dis :
- le test fonctionnel de bar qui appelle foo : obligatoire parce que c'est ce qui aurait permis de trouver le bug plus tôt, on aurait dû l'avoir avant.
- le test unitaire de foo : si ça te chante, que tu fais du TDD fais-toi plaisir. Franchement si ils je sont pas là ça ne m'empêchera pas de dormir.

Dit un peu autrement : quand on rajoute un test après avoir corrigé un bug, il faut que ce soit un test qu'on aurait été capable d'écrire avant d'avoir passé 2 jours à comprendre le bug. Si on se contente d'utiliser les connaissances qu'on a du vrai contrat pour changer le test unitaire, c'est de la merde. (Ok, ça rend le contrat explicite, c'est pas complétement inutile...)

 
Tu veux dire ceux qui ont des Apple store, ou des vergers avec pommiers ?  

Hepha: y a pas moyen de changer la visibilité de la méthode, histoire que ça soit plus clair?

Dommage

Vu le montant va falloir l'obtenir jeune et vivre vieux pour rembourser ! ^^

This

Vous êtes vraiment en train de faire des calculs de ROI financiers directs sur la légion d'honneur ?  

J'aimerais bien la demander pour le coup, ça fait chouette sur le costard en allant à la cogip

Bah vas y, à coup de réduction de temps d'exécution des tests d'une cogip dans un paradis fiscal ça passe peut être  

Les implications pour l'europe sont énormes.

Ça reste vrai dans la majorité des cas, les TU sont beaucoup plus rapide que les autres types de tests.

Force pas trop dès le début, il faut aussi penser à la montée en grade et en garder sous le pieds !

Non on peut pas, c'est le framework qui l'impose. Après je pense que c'est un pattern valide : on sépare un module en deux modules Foo et Bar, Foo est utilisé par Bar. Foo n'a pas vocation et est sans doute inutile sans Bar, je trouve souvent judicieux de ne tester que Bar, sans mocker Foo.
 
Un cas particulièrement courant dans notre équipe c'est quand Foo gère les accès en base de données, et expose des méthode de lecture et écriture. Ou alors, en frontend on utilise ngRX, c'est que ça : 3 modules (selecteurs, réducteurs et effets) qui sont tous les 3 utilisés dans l'application qui s'en sert pour gérer son état.
 
Si on veut n'écrire que des test unitaires, on va test Bar en mockant Foo d'une part, et Foo d'autre part. Ce que j'en pense :
- Tester Foo ne sert probablement à rien si on teste Bar sans mocker Foo (dans les faits, selon la complexité de Foo ça peut quand même être justifié).
- Mocker Foo ne sert qu'à rendre les tests plus rapide, mais il les rend moins utiles du même coup, et pas plus facile à écrire ni plus expressifs. Si ça ne tenait qu'à moi, je ne le ferais jamais. Que des tests qui ont une vraie base de donnée (de tests), qui mettent des secondes à s'exécuter. De toutes façon je suis un boomer, j'ai un clavier en US INTL avec touches mortes, j'appuie deux fois pour faire un guillemet, je suis pas à ça près. (En vrai je sais que c'est pas bien de dire ça, mais je défonce tellement la plupart des pinpins à barbe collier sur toutes les métriques de productivité, j'arrive pas à prendre cet argument au sérieux.)

Tu dois être trop jeune pour avoir connu les tests avant les containers voir la virtu    
Sur des tests bout en bout on a du réduire de trois ou quatre ordre de grandeur  

Non, j'ai connu, j'ai de plus en plus de cheveux blancs

Mais même avec les containers mon propos reste vrai, les TU sont plus rapides que tous les autres types de tests.

Le temps d'exécutions des TI à réduit drastiquement néanmoins.

Je vais étoffer mon propos : pour moi ce n'est pas parce que les tests fonctionnels ainsi que d'intégration sont plus rapide qu'avant que c'est une raison pour écrire moins de TU.

Les TU sont généralement purement métier, c'est tout autant ton contrat que ta doc.

Par contre je rejoins nuclearflo sur le fait que maintenant la majorité des devis sont du dev web et que finalement tu as très peu de métier, la plupart du temps on manipule de la donnée en faisant confiance au framework et à l'ORM, les TU sont de facto moins nombreux (sauf si vous faites comme chez nous, que vous mockez la terre entière pour produire des TU qui ne restent rien mais sont un enfer lord d'un refacto )

Tout à fait. Mais ça reste très coûteux à écrire je trouve.

Je connais faker, j'avais même fait une extension npm qui rajoutait du sucre par dessus pour générer des masses de données avec des ratios.

Genre si je voulais générer des peoples mais genre 24% de femmes et 64% d'hommes. En gros on pouvais faire des rations sur des groupes de valeurs, c'était assez utile pour une app avec des graphs

Mais dans mon contexte j'avias juste besoin de 10 "stores" afin de pouvoir les afficher sur une map en attendant la liste complète.

Edit :
Je sors les gros outils que lorsque je vois que je commence à en avoir vraiment besoin.
faker je pense que je le sortirais en cours de route si vraiment c'est nécessaire, mais même pas sûr.
Et un autre truc qui me fait chier ce sont les mecs qui rajoutent des libs de date alors qu'il n'y a qu'une simple putain de conversion de date à faire dans leur putain d'application. Alors on a eu moment.jd, date.jd, maintenant c'est dayjs, le plus petit, mais franchement, à partir du moment où la date qui t'es envoyée depuis les API c'est au format string ISO standard, et que toi tu dois juste formater en pouvant utiliser des DD/MM/JJ mm:ss:hh bah ya vraiment pas besoin de sortir dayjs et une fonction en 10 lignes fait tres bien le taf.

Ça dépends des langages / frameworks, la stack que j'utilise c'est pas bien compliqué

C’est plus l’inverse pour moi, tes flux métiers ils sont dans les TI, c’est ça qui teste le truc final / demandé.
 
Le TU, c’est pour des tests techniques de sous-composants (~détails d’implémentation), généralement parce-que faire tourner le TI 100 fois avec des variations mineures c’est chiant et lourd quand tu peux TU le composant pour regarder si tous ses edge cases sont comme tu veux (niveau TU tu peux juste prendre des représentants des classes d’erreur).
 
Tu peux même vouloir tester des cas limites qui sont pas actuellement atteignable via TI, mais des changements futurs pourraient les exposer et tu veux t’assurer que le comportement est régulier même si aucun TI n’est fait à ce moment.

Wat ??    
 

Wat ??²²²        
 
 
 
 
Sinon tu vas bien ? Tu sens le burn-out venir ?

Tout le monde ne peut pas être 10x programmateur  

this

 
+1
 
Et tester une méthode privée, ça implique de bidouiller le code pour qu'elle soit testable => pour moi c'est un mauvais plan.

Et éviter ce futur cas au niveau du code "principal" en acceptant un objet plus spécifique en entrée de foo, ça marche pas ? J'ai eu régulièrement le même type de problème dans le passé parce que sur une app Python, on avait des fonctions qui acceptaient des gros dictionnaires avec, à l'époque ou ces fonctions ont été écrites, des suppositions sur ce que contenait ce dictionnaire et/ou la valeur qu'avait certaines de ces clefs... Sauf que avec le temps forcément ces suppositions ne tiennent plus, du coup quand dans foo tu essayes d'accéder à une clef manquante, ou à une valeur qui est à None alors que ça devrait être une string, ça pète.
Et on a souvent solutionné ça en renforçant l'interface de foo, en acceptant non plus un dict en input, mais un "vrai" objet typé (genre class ou namedtuple par exemple) qui te fournit déjà plus de garanties (a minima un set commun de propriété et en fonction de comment ta class est instanciée, tu peux du coup aussi garantir que ces propriétés ont un set de valeur restreint)

Du coup je trouve dommage que ce contrat explicite il ne soit visible que via un TU et pas directement dans la signature de la fonction en question en fait (après je sais que c'est pas toujours possible, mais ça devrait être plus l'exception que la règle imho)