[New] Respecter la pyramide des tests

[ddebarbieux]

Sur certains projets, l'infrastructure de tests est plus grosse que celle de production : corriger une faute d'orthographe génère un build de plusieurs dizaine de minutes.

Les tests les plus coûteux (bout en bout d'IHM) ne sont pas à éxécuter systématiquement. Respecter la pyramide des tests (commencer par les tests unitaires).

[fzaninotto]

Sur la plupart ds projets, l'infrastructure de développement et de build est minime par rapport à celle de production. Se concentrer sur la consommation des serveurs de développement, c'est à mon sens passer à côté de l'essentiel - le scope 3.

[ACTLEM]

Tout dépend du nombre d'utilisateurs du services. Je suis tombé sur un seul cas où l'usine de build et de tests avait un impact relatif sur le service web car le service était utilisé par 5 personnes et que les environnements pré-production étaient surtaillés. Par contre, c'est un cas exceptionnel et dans mes autres expériences on est plus dans le cas exprimé par @fzaninotto sans compter le plus important qui est qu'en général ces infrastructures sont très mutualisées dans les grandes DSI ou chez les éditeurs.
Je comprends par contre qu'avoir toute une usine de build qui se lance pour une faute d'orthographe est du gâchis et est très frustrant. Seulement rapporté au nombre d'utilisations du service cela peut être anecdotique (c'est ce que montre en général les ACV d'un service numérique basée sur une archi web) surtout en cas de mutualisation de cette infrastructure et mise en arrêt du serveur quand il n'est pas utilisé. Mais même si d'un point de vue écoconception, le gain reste minime, cela n'empêche pas de faire preuve de bon sens pour avoir une boucle de feedback raccourci ;)

[rlemaire]

Il y a souvent des questions sur l'impact de l'intégration continue et comment le réduire. Ca vient beaucoup du biais classique que les gens commencent par vouloir réduire ce qu'ils sont sous les yeux et ce qu'ils contrôlent.

Mais aussi c'est vrai qu'il n'y a pas si peu de projets que ça avec assez peu d'utilisateurs par rapport à la taille de l'équipe de développement, et où du coup la vie de bureau et l'IC devient importante dans le total. Je ne sais pas si ce serait à inclure dans le top 115, mais c'est vrai que des idées d'optimisations à ce niveau intéressent les gens.

[devcrafting]

Je me dis qu'il serait utile aussi de déconstruire cela dans le livre, soit avec des "fausses bonnes pratiques", soit avec une section à ce sujet

[ACTLEM]

#139