Design & Développement web - Le topic des canards qui mangent des cookies

[raaaahman]

Les katas c'est assez sympa pour pratiquer le TDD. C'est aussi amusant à faire en groupe (les "dojos") pour se confronter aux visions d'autres devs. Je ne pense pas que l'on devienne meilleur en codant tout les jours comme on l'a fait la veille.

Oui on pourrait envisager faire de l'entrainement sur son temps de travail, ça ne serait pas du temps perdu pour l'entreprise (même si c'est compliqué de leur faire comprendre en général). Ceci dit, si vous comptez changer de boîte un jour (et je ne pense pas que l'on puisse rester 40 ans au même endroit), il faudra savoir se mettre à la page tout seul sur les nouvelles technos/pratiques. Moins sur l'aspect clean code/craftsmanship/etc., car chaque boîte va avoir sa propre définition des "bonnes" pratiques.

[Awake]

Je pense que faire des exercices de temps en temps pour s’entraîner à l'algorithmique ou apprendre de nouveaux langages ou frameworks est bien entendu utile. Sur son temps libre ou au boulot d'ailleurs, je ne suis pas convaincu que toutes les formations devraient être faites sur le temps de l'employeur. Passer une soirée de temps en temps à apprendre un nouveau truc, ou un samedi après midi, pas de soucis ama. Mon boulot est toujours une passion donc ça ne me dérange pas. Mais 3 heures tous les jours, c'est de la folie.

Par contre, les ingénieurs en aérospatial ne s'amusent pas à résoudre des transformations de Fourier (ou autre, je n'y connais rien) pour "se chauffer" tous les matins comme le conseille oncle bob. Et eux sont considérés comme des professionnels. Et en plus appeler ça des Katas, comme si on pratiquait un art martial... que c'est malvenu.

[raaaahman]

Genre les ingénieurs d'Apollo 1? Ou ceux de Falcon 1?

[Dross]

3h par jour c'est du délire.

Après, je trouve qu'il y a une grande différence entre un profil qui code sur son temps libre (que ça soit toutes les semaines ou une fois tout les six mois) et celui qui ne le fait jamais. Perso, entre deux profils je préférerai toujours le premier cas : c'est un passionné et il faut l'être un peu dans ce métier.

Car faut pas oublier un truc : entre un ingé méca et un ingé logiciel, on n'a pas exactement le même salaire (et je suis bien placé pour le savoir : j'ai fait un diplôme d'ingé en mécanique, et était atterré des différences, qui font que j'ai bifurqué avant la fin vers le logiciel (via un double diplôme)) et je pense que ça justifie d'en faire un peu plus dans les "à cotés".

Chez nous on donne du temps de formation, mais j'aime aussi me former sur mon temps libre car ça me permet de regarder des techs qui ne sont pas forcément utile (aujourd'hui) dans mon travail.

[Orhin]

Perso, entre deux profils je préférerai toujours le premier cas : c'est un passionné et il faut l'être un peu dans ce métier.

Boaf.
Je vois pas le rapport entre coder sur son temps perso et être passionné par son métier.

J'adore mon métier et j'hésite pas à faire plus pour le boulot quand y'a besoin.
Je suis référent technique front dans ma boite (et dans l'ancienne).

Pourtant je ne code jamais sur mon temps libre (je sais même pas quand je pourrais prendre le temps de faire ça en fait).
Les seules fois où je l'ai fais c'était pour aider des potes (reconversion pro et équilibrage de jeu de société).

À côté, des collègues qui ont des projets perso mais qui sont moyens techniquement et/ou font le strict minimum, j'en ai vu un paquet.

[Dross]

Ce n'est pas mes observations de mon coté, mais il peux toujours y avoir des exceptions.

Ceux qui codent sur leur temps libre ont souvent commencé la programmation avant de suivre une formation / d'en faire un métier. Techniquement et au niveau de l'intérêt / curiosité c'est toujours des profils assez forts.

Ceux qui ne codent pas sur leur temps libre, souvent sont parti dans la programmation par défaut, souvent plus intéressés par les salaires qu'autre chose. Pas forcément des mauvais profils, mais bon quand tu part dans une activité en mode alimentaire...
Et avec les grosses vagues de reconversion actuelles, préparez vous à en voir encore plus qu'avant.


Après, c'est probablement plus important en sortie d'école / début de carrière, que pour les seniors en effet.
Mais un jeune qui sort d'école et qui a rien à coté, pour moi c'est le méga red flag.


ps : et j'insiste bien, je parle bien de ne jamais coder sur son temps libre. Même quand on a X ou Y problème informatique qui pourrai être résolu avec, ou régler tel aspect de ton système de domotique / media center / etc, se faire une app Android pour se rendre la vie plus facile sur Z, etc.

[Orhin]

Ce n'est pas mes observations de mon coté, mais il peux toujours y avoir des exceptions.

Ou alors y'a pas vraiment de règles et tes observations (ainsi que les miennes) sont biaisées.

Ceux qui codent sur leur temps libre ont souvent commencé la programmation avant de suivre une formation / d'en faire un métier. Techniquement et au niveau de l'intérêt / curiosité c'est toujours des profils assez forts.

Ceux qui ne codent pas sur leur temps libre, souvent sont parti dans la programmation par défaut, souvent plus intéressés par les salaires qu'autre chose. Pas forcément des mauvais profils, mais bon quand tu part dans une activité en mode alimentaire...

Je suis désolé mais on dirait du https://twitter.com/DisruptiveHoLin tellement c'est caricatural.

Et avec les grosses vagues de reconversion actuelles, préparez vous à en voir encore plus qu'avant.

Ça pour le coup ça peut s'entendre en effet.
On reste dans un secteur qui recrute beaucoup alors que pas mal d'autres pans de l'économie sont à l'arrêt à côté.

Mais un jeune qui sort d'école et qui a rien à coté, pour moi c'est le méga red flag.

Ah bah au contraire je préfère un jeune qui a profité de sa vie étudiante pour booster ses sociales (en faisant de l'associatif par exemple) plutôt que quelqu'un qui restait enfermé dans sa chambre à coder.
Moi aussi je peux faire des généralités trollesques.

Surtout qu'un jeune qui sort d'école ne connait par définition pas grand chose et apprendra plus pendant ses 6 premiers fois (qui peuvent être aussi son stage de fin d'étude) que pendant sa scolarité.

ps : et j'insiste bien, je parle bien de ne jamais coder sur son temps libre. Même quand on a X ou Y problème informatique qui pourrai être résolu avec, ou régler tel aspect de ton système de domotique / media center / etc, se faire une app Android pour se rendre la vie plus facile sur Z, etc.

Ben dans les faits ce genre de cas est relativement rare.
Perso le seul moment où j'ai été motivé pour le faire c'était pour une appli de suivi de partie de JDS.
Sauf que y'a déjà plein d'alternatives très bien foutues, du coup j'ai préféré faire plus de partie de JDS que de coder.

[Dross]

Bah justement, y'a des étudiants qui ont des projets en plus de l'associatif, c'est effectivement un profil encore plus intéressant que celui qui n'aura qu'un des deux, c'est pas du tout incompatible (et c'est l'ancien président du club photo de mon école d'ing qui te le dit, qui a mis en place des amphi animé par des pros, remit le labo en état de marche en dénichant des agrandisseurs, organisait sortie photos de tout type jusqu'à l'urbex, des formations en technique photo et retouche photoshop que j'animais moi même, etc).

Et dans ce cadre j'ai aussi codé un site web pour le club. Mon portfolio photo a toujours été 100% custom (dont les premières versions datent de cette époque). J'ai monté un site de vulgarisation de post-traitement. Etc.

T'est en école, pas en prépa, t'a du temps faut pas déconner.

Et perso ce genre de cas je trouve que ce n'est pas si rare justement : quand je me suis mis à la basse, j'ai suivi un cours en ligne, le truc était bien mais le truc de suivi était pourri, j'aurai aimé un truc en ligne, simple, bah je l'ai fait. Les cours dans lesquels je m'investissais alors était de 1-2h par soir pendant 2-3 mois, alors 2-4h de code pour avoir un truc comme je voulais c'était un investissement tout à fait raisonnable.

Ce genre de trucs ça m'arrive tout le temps.

[raaaahman]

To TDD or to not TDD? La sempiternelle question...

EDIT: Voir message de Foksadure

J'ai beau apprécier la pratique, la difficulté d'écrire des tests pour le front-end me dissuade aujourd'hui totalement de persévérer dedans. Tellement de galère à chaque fois qu'il faut utiliser une API du browser ou configurer la suite avec une bibliothèque/un framework (React, Next, Firebase, etc.).

[Awake]

La vidéo ne marche pas chez moi.

Plus ça va, plus je me dis que le e2e est la meilleure des solutions : test à la fois le front et le fonctionnement global de l'app. Note que ça n'empêche pas de faire des TU backend et pour certaines fonctions front, ama les deux se complètent.

[Foksadure]

Encore un truc mis en ligne sans être testé. User Test Driven Development.

[Awake]

Sympa la video !

Par contre j'arrive vraiment pas à assimiler "ecrire les tests en premier". En pratique je ne vois pas du tout comment faire. Je suppose qu'on écrit pas 100 lignes de tests sur du code inexistant puis l'implémentation, il doit y avoir des allés retours entre les tests et le code. Vous auriez des bonnes ressources là dessus ? Dans la vidéo ils parlent de faire des KATAs, au delà du nom douteux j'aimerais en savoir plus

[William Vaurien]

J'ai jamais réussis à écrire du test en premier, à part pour du code de calculs arithmétique, de manipulation de données simples (genre un détecteur de patterns basés sur une regexp) ou d'aiguillage à base de conditions booléenes...

Dès que c'est plus complexe j'ai besoin de faire un brouillon de code qui va évoluer... Donc les tests arrivent après, une fois le code passé au propre.

Peut être que je rate un truc, qu'écrire le code en premire reviendrai à faire ce brouillon sous forme de test, et aussi éviter que le brouillon devienne code de prod par la force des choses (délai court, flemingite...). Mais je suis sceptique pour des truc un peu complexe...

[raaaahman]

Encore un truc mis en ligne sans être testé. User Test Driven Development.

Oups, spotted!

Pour une application du TDD en React, j'avais bien aimé cette ressource: https://learntdd.in/react/ Ou les vidéos associées https://www.youtube.com/playlist?lis...2wilxymcOaVl9Q, même si c'est techniquement daté (2018! la préhistoire en années front-end ), l'approche était bien expliquée.

Après chacun voit midi à sa porte bien spur, il n'y a pas une seule méthode de faire du TDD.

EDIT: Si vous voulez, on peut s'organiser un dojo* un de ces quatres.

*Nom sujet à changement, selon l'inspiration d'Awake.

---

Sinon je change de sujet, mais en terme de déploiement d'applis Next.JS, à part Vercel; quels autre options valent le coup? Une boîte européenne compatible RGPD de préférence. Je sais que la question est vague et qu'il y a pas mal de paramètres à prendre en compte, j'aimerais juste avoir quelques retours d'expériences, positives comme négatives.

[Awake]

De ce que j'avais vu en regardant, next.js est quand même tres lié à Vercel. En tout cas j'avais abandonné de le faire tourner sur l'infra Cloudflare.

Pour revenir aux tests, j'ai une question d'architecture qui a émergée lorsque j'ai fait des tests sur un projet Java. Exemple imaginaire :

Admettons qu'on ait un service backend CanardWebsite qui va charger et parser des informations du forum CPC. Une méthode public "getDuckProfile" a laquelle on passe l'url d'un profil d'un canard et qui retourne une petite structure avec des données (pseudo, avatar, etc).

Avant tout, je veux valider que l'url appartiens bien à l'host forum.canardpc.com et que le path est bien celui qui mène à un profil membre :
- faire les verifications directement dans la méthode : pour moi c'est non, ça fait une méthode à rallonge
- appeler une methode privée qui s'occupe de la validation : si pas valide, on jette une InvalidUrlException depuis getDuckProfile. C'est ce que j'avais fait au début, mais comme ma méthode est privée, je ne pouvais pas la tester !
- passer la méthode privée de validation en public ? si pas besoin ailleurs que dans la classe CanardWebsite, ça ne me semble pas une bonne idée
- faire un autre service CanardWebsiteProfile qui s'occupe de tout ce qui est en lien avec specifiquement les profiles sur le forum. Du coup CanardWebsite pourrait appeler canardWebsiteProfile.validateUrl(url) et eventuellement d'autres fonctions pratique comme canardWebsiteProfile.extractAvatarUrl(html) etc.

Au final j'ai choisi la dernière solution, mais je me demande si remplacer les fonctions privées par des services/classes enfantes est une si bonne pratique que ça ? Si non, comment tester ses fonctions privées ? Oncle Bob doit en parler dans Clean Code, mais j'ai oublié ..

[war-p]

J'ai jamais réussis à écrire du test en premier, à part pour du code de calculs arithmétique, de manipulation de données simples (genre un détecteur de patterns basés sur une regexp) ou d'aiguillage à base de conditions booléenes...

Dès que c'est plus complexe j'ai besoin de faire un brouillon de code qui va évoluer... Donc les tests arrivent après, une fois le code passé au propre.

Peut être que je rate un truc, qu'écrire le code en premire reviendrai à faire ce brouillon sous forme de test, et aussi éviter que le brouillon devienne code de prod par la force des choses (délai court, flemingite...). Mais je suis sceptique pour des truc un peu complexe...

Bah, en général, le rule of thumb, c'est d'identifier vers quoi tu veux avec aller comme transformation depuis des données d'entrée que tu connais.
Tu code donc tes données en entrée, tu codes ce qui va valider tes données en sortie et voilà, t'as plus qu'à te démerder pour que tout colle.
En général comme le cerveau humain ne permet pas de tout envisager, tu te retrouves à coder plein de petites fonctionnalités toutes testées séparément, et quand tu mets tout ensemble, c'est censé fonctionner. (Jusqu'à ce que ton chef de projet/po change d'avis sur la spec)

- - - Mise à jour - - -

Après, rien ne t'empêche de faire vivre ton test pendant le dev, genre pour gérer les cas d'erreur spécifiques aux api des bibliothèques par exemple.

[Hideo]

De ce que j'avais vu en regardant, next.js est quand même tres lié à Vercel. En tout cas j'avais abandonné de le faire tourner sur l'infra Cloudflare.

Pour revenir aux tests, j'ai une question d'architecture qui a émergée lorsque j'ai fait des tests sur un projet Java. Exemple imaginaire :

Admettons qu'on ait un service backend CanardWebsite qui va charger et parser des informations du forum CPC. Une méthode public "getDuckProfile" a laquelle on passe l'url d'un profil d'un canard et qui retourne une petite structure avec des données (pseudo, avatar, etc).

Avant tout, je veux valider que l'url appartiens bien à l'host forum.canardpc.com et que le path est bien celui qui mène à un profil membre :
- faire les verifications directement dans la méthode : pour moi c'est non, ça fait une méthode à rallonge
- appeler une methode privée qui s'occupe de la validation : si pas valide, on jette une InvalidUrlException depuis getDuckProfile. C'est ce que j'avais fait au début, mais comme ma méthode est privée, je ne pouvais pas la tester !
- passer la méthode privée de validation en public ? si pas besoin ailleurs que dans la classe CanardWebsite, ça ne me semble pas une bonne idée
- faire un autre service CanardWebsiteProfile qui s'occupe de tout ce qui est en lien avec specifiquement les profiles sur le forum. Du coup CanardWebsite pourrait appeler canardWebsiteProfile.validateUrl(url) et eventuellement d'autres fonctions pratique comme canardWebsiteProfile.extractAvatarUrl(html) etc.

Au final j'ai choisi la dernière solution, mais je me demande si remplacer les fonctions privées par des services/classes enfantes est une si bonne pratique que ça ? Si non, comment tester ses fonctions privées ? Oncle Bob doit en parler dans Clean Code, mais j'ai oublié ..

Pour moi si ta method est private du coup pas besoin de la tester puisque qu'elle le sera implicitement par ta methode publique qui l'appel. On ne veut pas tester toutes les lignes de code, on veut tester les comportements qui sont interessants a tester, une "unite". Une methode privee ne veut "rien dire" d'elle meme.
Donc j'aurai choisi la deuxieme option, ta method privee balance une erreur et tu test que la publique la balance bien quand tu passes un arguement qui foire.

Et je crois me rappeler qu'en C# il y a definition de method qui rend ta methode privee mais publique dans le cas de tests. Je sais pas d'ou je sors ca.

[raaaahman]

- faire un autre service CanardWebsiteProfile qui s'occupe de tout ce qui est en lien avec specifiquement les profiles sur le forum. Du coup CanardWebsite pourrait appeler canardWebsiteProfile.validateUrl(url) et eventuellement d'autres fonctions pratique comme canardWebsiteProfile.extractAvatarUrl(html) etc.

En terme d'architecture ça ne me paraît pas déconnant. Mais je soupçonne que ta classe CanardWebsiteProfile ne maintienne pas d'état interne, auquel cas tu peux remplacer tes méthodes d'instances par des méthodes statiques, et la testabilité s'en trouvera nettement simplifiée.

Mais tester les méthodes privées peut s'avérer casse-pieds en effet. Un langage qui implémente ce mécanisme devrait aussi proposer une manière de le contourner dans des environnements spécifiques, comme le test. En PHP j'utilisais les Reflections pour le faire. Si ton langage ne propose aucun mécanisme du genre, tu as toujours le choix de passer tes méthodes en protégées à la place de privées, et de sous-classer dans tes tests.

Le commentaire d'Hideo fait référence à une considération courante dans le milieu: "White Box Testing vs. Black Box Testing". Ou, en gros, faut-il tester les détails d'implémentation? Je pense que la question s'étudie au cas par cas.

[Awake]

D'accord ce que je n'avais pas bien assimilé qu'on est sensé testé uniquement que ce qui est visible, dans la théorie en tout cas.

On peut donc :
- tester uniquement ce qui est public, du moment que la classe ne fait pas trop de choses différentes
- si la classe commence à gonfler, on créer une sous classe qui va s'occuper de certains traitements -> on pourra alors la tester car forcément elle aura ses propres méthodes visibles. Autre possibilité, faire du polymorphisme et éclater la classe qui prend de la place en plusieurs services sur lesquels itérer
- dans certains cas, on voudra tout de même tester des fonctions privées (dans quels cas ?), deux possibilités : transformer la visibilité de la méthode au runtime des tests (possible en Java, PHP, Typescript), ou, passer la méthode en protected et faire une sous classe pour les tests qui rend visible la méthode (j'aime moins)

Ca vous semble tenir la route ?

[GrandFather]

J'ai toujours lu et entendu dire que le test unitaire de méthodes privées était une mauvaise pratique, et que la volonté d'en faire trahissait en fait un défaut d'architecture. Et ça recoupe mes propres constatations : à chaque fois que j'ai voulu tester une méthode privée, ça a plutôt débouché sur un refactoring bienvenu.

[William Vaurien]

Admettons qu'on ait un service backend CanardWebsite qui va charger et parser des informations du forum CPC. Une méthode public "getDuckProfile" a laquelle on passe l'url d'un profil d'un canard et qui retourne une petite structure avec des données (pseudo, avatar, etc).

Au final j'ai choisi la dernière solution, mais je me demande si remplacer les fonctions privées par des services/classes enfantes est une si bonne pratique que ça ? Si non, comment tester ses fonctions privées ? Oncle Bob doit en parler dans Clean Code, mais j'ai oublié ..

D'accord ce que je n'avais pas bien assimilé qu'on est sensé testé uniquement que ce qui est visible, dans la théorie en tout cas.

On peut donc :
- tester uniquement ce qui est public, du moment que la classe ne fait pas trop de choses différentes
- si la classe commence à gonfler, on créer une sous classe qui va s'occuper de certains traitements -> on pourra alors la tester car forcément elle aura ses propres méthodes visibles. Autre possibilité, faire du polymorphisme et éclater la classe qui prend de la place en plusieurs services sur lesquels itérer
- dans certains cas, on voudra tout de même tester des fonctions privées (dans quels cas ?), deux possibilités : transformer la visibilité de la méthode au runtime des tests (possible en Java, PHP, Typescript), ou, passer la méthode en protected et faire une sous classe pour les tests qui rend visible la méthode (j'aime moins)

Ca vous semble tenir la route ?

Je serais parti également sur ta dernière option Awake.
Si ton backend est basé sur de l'injection de dépendance (Spring ou autre), c'est extrémement simple d'ajouter un service, et de le tester proprement.
Et comme ça tu sépareras bien les responsabilités de tes différents services.
Tu peux aussi faire une classe utilitaire, avec des méthodes static à la manière des StringsUtils, IOUtils, FileUtils, etc.
Tu gardes l'idée de bien séparer les rôles et d'avoir des tests sur les différents composant.
Les classes utilitaires avec méthodes static sont juste pénible à modifier pendant les tests: un service auxiliaire peut être remplacer facilement au moment du test par une autre implémentation pour ne pas créer de 'bruit' pendant le test du service.

Les méthodes privées et les tests c'est un vieux débats et un sujet à controverse... Je suis à la fois d'accord avec raaaahman et GrandFather: on devrait pouvoir tester les méthodes privée au besoin; même si le fait de devoir les tester révèle peut être un défaut d'architecture...

Pour le changement de visibilité en protected: les devs de Spring (et d'Android) ont introduit une annotation '@VisibleForTesting' qui permet de marquer ce genre de 'tromperie' comme étant volontaire dans le but de tester des méthodes qui auraient du être privées (qui ne le sont plus vraiment pour le coup). Il y a bien un besoin qui nécessite un contournement un peu moche. J'essaie d'éviter le plus possible. Ensuite on peut faire ressortir des mauvais usage avec de l'analyse statique (mais ça ne sent pas très bon...)

J'ai du coup l'habitude d'avoir des 'micro-composants' (au sens d'une classe type Service avec une ou deux méthodes) dans mes backends pour pouvoir les tester et d'avoir moins de méthodes privées. Généralement j'essaie de me retrouver avec une interface (les points d'entrée public) qui utilise les parties privées de la classe et qui permet de de tester l'ensemble.

Par contre je ne trouve pas que l'idée de faire de l'héritage pour contourner le problème soit très bonne. Passe plutôt par de la composition: ton service CanardService utilisera dorénavant CanardValidationService en auxiliaire et ce dernier aura son propre jeu de test...
Dans CanardService l'auxiliaire CanardValidationService sera privé et donc totalement innaccessible.

Bah, en général, le rule of thumb, c'est d'identifier vers quoi tu veux avec aller comme transformation depuis des données d'entrée que tu connais.
Tu code donc tes données en entrée, tu codes ce qui va valider tes données en sortie et voilà, t'as plus qu'à te démerder pour que tout colle.
En général comme le cerveau humain ne permet pas de tout envisager, tu te retrouves à coder plein de petites fonctionnalités toutes testées séparément, et quand tu mets tout ensemble, c'est censé fonctionner. (Jusqu'à ce que ton chef de projet/po change d'avis sur la spec)

Oui, quand le périmètre de la transformation est assez simple c'est facile de partir sur du test en premier. Après c'est pas toujours le cas, et dans ce cas les tests en premiers sont des entraves à une élaboration en plusieurs phases (après je fonctionne comme ça, c'est pas forcément le cas de tout le monde)...
Mais j'ai rarement vu des collègues faire du 'test first'.
C'est plutôt brouillon/stabilisation/tests avec les tests qui marquent à la fois le bon fonctionnement d'un ensemble et qui valident une archi...

Et je crois me rappeler qu'en C# il y a definition de method qui rend ta methode privee mais publique dans le cas de tests. Je sais pas d'ou je sors ca.

Je ne connais pas le C#, et je ne sais pas si cette feature existe vraiment, mais ça serait vraiment bien que les langages intègrent les tests directement (avec une infrastructure standard, des comportements différenciés)... Ca existe peut être dans certains langages ?

[Dross]

En C# y'a le "internalsVisibleTo" pour rendre des fonctions internes accessibles par un asm de tests, c'est de ce genre là : "[assembly: InternalsVisibleTo("ConfigTests, PublicKey=<PUBLICKEYVALUE>")]".

Mais ça se justifie beaucoup plus que de rendre des choses privées visibles par des tests : le besoin de tester des trucs internes n'est pas exactement le même que de vouloir tester des trucs privés (où en effet ce n'est pas une bonne idée 99.9% du temps).

Si vous voulez tester un truc privé, c'est le moment de refactoriser pour mettre cette logique dans une classe à part et l'injecter à celle qui l'utilise.



Pour écrire des tests avant, en général c'est pour du code de logique, pas vraiment l'UI. Par exemple t'a une classe qui doit additionner deux valeurs venant d'un service tiers, bah tu créer des mocks pour sortir lesdites valeurs, tu écrit ton test que la fonction doit récupérer et additionner les valeurs, puis tu peux écrire ton code.

Ecrire les tests avant ça permet en général d'avancer plus vite : car ça permet de se poser les bonnes questions, "qu'est-ce que cette classe est censée faire", "quelle ressources a-t-elles de disponibles", etc. Très très utile pour les débutants, et un bon garde fou pour les autres.

Mais cette méthode a encore plus d'intérêt quand tu corrige des bugs/du code : écrire le test avant la modification permet de valider que tu a bien compris l'origine du bug/problème (le test ne doit pas passer : car ton code n'est pas encore corrigé ; vous seriez surpris du nombre de fois où j'ai pus voir le test passer et me dire "merde, c'était pas ça le soucis") une fois vérifié que t'a bien isolé le problème, tu corrige le code. Et alors le test doit passer au vert sans correction, si ce n'est pas le cas, là encore faut retourner analyser ce qu'il se passe, car visiblement il y a une mauvaise analyse dans l'histoire.

[raaaahman]

Ca vous semble tenir la route ?

J'ai envie de dire oui, mais en rappelant que le test n'est pas une finalité, mais un outil. Découper une classe et y injecter une dépendance ça a de la valeur en terme de flexibilité de l'architecture, et de mainenabilité de l'application. Les tests sont juste supposés mettre ces avantages en exergue. Ca recoupe avec l'observation de GrandFatherBones:

J'ai toujours lu et entendu dire que le test unitaire de méthodes privées était une mauvaise pratique, et que la volonté d'en faire trahissait en fait un défaut d'architecture. Et ça recoupe mes propres constatations : à chaque fois que j'ai voulu tester une méthode privée, ça a plutôt débouché sur un refactoring bienvenu.

Tu as quand même un bénéfice à avoir voulu tester ta méthode privée, même si le résultat n'est pas une méthode privée testée. Je dirais que les tests unitaires ont rempli leur office.

Après j'ai du mal à voir le nombre de cas où il est intéressant d'avoir une méthode privée non testée. Soit elle est triviale, et dans ce cas, elle ajoute de l'indirection dans un code qui aurait pu être simplifié. Soit elle ne l'est pas, et il est intéressant de connaître son comportement isolé, notemment aux cas limites. Soit elle est réutilisée dans plusieurs méthodes publiques, et cela risque d'impliquer une multplication des tests de ces méthodes publiques pour couvrir tous les cas de la méthode privée Soit elle n'est utilisée que dans une seule méthode ppublique, et dans ce cas, on peut encore se demander la pertinence de l'avoir extraite ene premier lieu.

JLes classes utilitaires avec méthodes static sont juste pénible à modifier pendant les tests: un service auxiliaire peut être remplacer facilement au moment du test par une autre implémentation pour ne pas créer de 'bruit' pendant le test du service.

C'est vrai, j'avais oublié la galère que c'est de susbtituer un appel de méthode statique dans les tests par un bouchon. Ce n'est absolument pas trivial quand la dite méthode statique fait la connection à une base de données par exemple, ce qui change tout l'outillage nécessaire pour écrire les tests.

JC'est plutôt brouillon/stabilisation/tests avec les tests qui marquent à la fois le bon fonctionnement d'un ensemble et qui valident une archi...

Bah on est pas loin de la pratique tests firsts, tu peux l'adapter à ta sauce bien sûr. Juste que si tu veux être commencer par l'écriture du test, ltu t'intéresse en priorité au résultat attendu, plutôt qu'à la manière de l'obtenir. Tu peux travailler avec une approche dite "top down" si ta vision des étapes n'est pas encore très définie: commencer par un test haut niveau, genre test d'intégration ou end to end, puis descendre vers des tests unitaires au fur et à mesure que tu raffines l'architecture de ta solution.

Encore une fois, le but n'est pas de suivre un dogme sans s'en écarter. Si votre équipe arrive à améliorer sa vélocité et la maintenabilité des applications produites en piochant certaines idées dedans, c'est tout ce qui compte.

[Awake]

(Je viens d'y penser en attendant un bus, je la poste maintenant pour pas oublier.

Quel est la nourriture préférée des devs frontend ?

Spoiler Alert!

Les endives

Je sors.
)

[raaaahman]

Je l'ai pas... A part le "end" dans endives... Ou alors ça sonne comme "endif" (mais c'est pas du JS)?

[Awake]

Spoiler Alert!

En <div>

[Awake]

Pendant que vous finissez de rigoler à ma blague hilarante, j'aurais une autre question, plus devops cette fois : j'ai eu un entretient cet après midi, dans une grosse boîte (plusieurs milliers de personnes, ils ont leur propre mini-ESN en interne pour dispatcher les devs...), et ils ont abordé le workflow git. Je leur dit que je fais les classiques branches, puis code review, puis merge. Jusque là tout va bien, et je tente "mais j'ai aussi entendu parler de gens qui bossent sans branches" ... regards étonnés "C'est à dire ?" "Ben tout le monde boss dans main " et là j'ai eu une reaction immédiate de "oula non non pas une bonne idée".

Du coup... j'ai dit une connerie ? Vous avez de l'expérience de workflows autre que le "classique" ?

[tompalmer]

Ce serait pas comme si t'avais postulé pour etre graphiste en disant que tu bossais sans utiliser les calques dans Photoshop ?

Auquel cas t'as du passer pour un zouave du codage dans sa tete

[Orhin]

Disons que ça va beaucoup dépendre de la culture d'entreprise et des connaissances techniques des personnes.
Le trunk-based development est une vraie pratique qui peut tout à fait se justifier.
Même si ça nécessite quand même pas mal de prérequis pour que ce soit possible (et personnellement je n'en suis pas trop fan).

[Dross]

Bosser sans branches c'est techniquement faisable mais c'est un peu con si tu a un outil qui le supporte.

Même en solo c'est avantageux de travailler avec des branches : en travaillant sur une fonctionnalité par branche ça te permet de changer d'avis et de sortir F3 puis F1, alors que tu avais commencé à travailler sur F1 puis F2 puis F3. En travaillant au même endroit ce n'est pas possible.
Si t'a un soucis lors du merge, le revert est plus facile/propre aussi.
Garder une branche stable "en prod" permet de patcher un soucis live et de passer la modif aux choses en dev ensuite.

Bien sûr, tout ça est encore plus vrai en équipe.

Pour moi la différence ça va être au niveau de la rigidité de ton système de branche : par exemple sur TFS tu ne fait pas 1 fonctionnalité par branche car elles sont très rigides et merdiques. Donc tu te retrouve potentiellement juste avec Release/Stable/Dev. Sur git, comme tu peux merge n'importe qui avec n'importe quoi ça te permet plus de libertés, et donc avoir Master/Feature_X/Fix_X.

Gérer les releases avec des branches distinctes, ou juste les tags. Là aussi la rigidité du système risque d'orienter pas mal ton choix.

Mais bosser dans une seule branche, wai non, jamais une bonne idée.