Si ça part au mec produit, il change la spec et tu repart au début.
Et la le dev râle parce qu'il doit réécrire des tests pour la même feature :D
2nd itération. 3ème.
Au bout de la 4ème itération, le dev commence a en avoir marre et commencera a bâcler les tests. À raison.
C'est peut-être l'indication, justement, que d'écrire les tests pour ce qui est, au final, un PoC, c'est une perte de temps.
Ne serait-ce pas plus efficace d'avoir une feature demandée, un dev qui code une PoC, l'envoyer en "qa laxiste" pour voir ce que ça donne (un PoC, on sait que ça va péter, la question c'est de savoir si c'est ça qui est voulu ou pas, grosso merdo), et si ça passe, alors finaliser en mettant à jour les specs, la couverture de tests et nettoyer le code (parce qu'un code de PoC, c'est rarement clean, s'pas le but faut dire)?
Mon histoire à moi, c'est ça:
La seule fois où j'ai tenté de maintenir une batterie de tests, de ma propre initiative (j'étais tout seul sur le projet de toute façon, la boîte était une SSI de moins de 10 personnes), c'est exactement ce qui est arrivé: le client cassais tout le temps tout, donc je perdais tout mon temps a réécrire les tests, 4 ou 5 fois plus qu'a avancer sur le projet.
Donc au bout de 1 ou 2 mois, j'ai rm -rf le dossier et arrêté de me prendre trop la tête, au point d'avoir une injection sql dont je n'avais rien à foutre (bon, il y a eu d'autres trucs qui m'ont démotivé, certes, mais ça a joué énormément).
De nos jours, une telle situation se reproduirait, je dirais franco au client d'arrêter de tout péter, et que s'il arrive pas a se décider sur l'interface, je vais trancher, moi. Et si ça pose un souci, au pire j'me casse (oui, de la boîte, et démerdez-vous). Mais je n'avais pas encore le caractère formé, à l'époque.
En tout ça, cette expérience m'a vacciné contre tout process qui me force à écrire les tests avant le code d'une nouvelle feature.
C'est juste largement trop extrême.
Je ne dis pas que les tests auto ça sert à rien, loin de là, mais le moins y'a de code a écrire, le mieux je me porte, je préfère largement faire tourner un compilo en mode facho ou un outil d'analyse statique, malgré les faux positifs, ça me semble un meilleur usage de mon temps.
D'ailleurs, à l'époque, Apple (ils sont revenus plusieurs fois dans la discussion comme symbole de qualité... lol) n'avait pas encore eu son goto-fail, et j'avais, justement, déjà réglé mon compilo et mon style de codage pour rendre ce bug entièrement impossible. Sans écrire le moindre test.
Après, je sais que le sujet du journal est lié aux tests d'UI, mais la discussion ici me semble avoir assez dérivé, donc ce commentaire n'est pas trop à côté de la plaque j'espère?
[^] # Re: Tests différents (ou partiels)
Posté par freem . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
Et la le dev râle parce qu'il doit réécrire des tests pour la même feature :D
2nd itération. 3ème.
Au bout de la 4ème itération, le dev commence a en avoir marre et commencera a bâcler les tests. À raison.
C'est peut-être l'indication, justement, que d'écrire les tests pour ce qui est, au final, un PoC, c'est une perte de temps.
Ne serait-ce pas plus efficace d'avoir une feature demandée, un dev qui code une PoC, l'envoyer en "qa laxiste" pour voir ce que ça donne (un PoC, on sait que ça va péter, la question c'est de savoir si c'est ça qui est voulu ou pas, grosso merdo), et si ça passe, alors finaliser en mettant à jour les specs, la couverture de tests et nettoyer le code (parce qu'un code de PoC, c'est rarement clean, s'pas le but faut dire)?
Mon histoire à moi, c'est ça:
La seule fois où j'ai tenté de maintenir une batterie de tests, de ma propre initiative (j'étais tout seul sur le projet de toute façon, la boîte était une SSI de moins de 10 personnes), c'est exactement ce qui est arrivé: le client cassais tout le temps tout, donc je perdais tout mon temps a réécrire les tests, 4 ou 5 fois plus qu'a avancer sur le projet.
Donc au bout de 1 ou 2 mois, j'ai
rm -rfle dossier et arrêté de me prendre trop la tête, au point d'avoir une injection sql dont je n'avais rien à foutre (bon, il y a eu d'autres trucs qui m'ont démotivé, certes, mais ça a joué énormément).De nos jours, une telle situation se reproduirait, je dirais franco au client d'arrêter de tout péter, et que s'il arrive pas a se décider sur l'interface, je vais trancher, moi. Et si ça pose un souci, au pire j'me casse (oui, de la boîte, et démerdez-vous). Mais je n'avais pas encore le caractère formé, à l'époque.
En tout ça, cette expérience m'a vacciné contre tout process qui me force à écrire les tests avant le code d'une nouvelle feature.
C'est juste largement trop extrême.
Je ne dis pas que les tests auto ça sert à rien, loin de là, mais le moins y'a de code a écrire, le mieux je me porte, je préfère largement faire tourner un compilo en mode facho ou un outil d'analyse statique, malgré les faux positifs, ça me semble un meilleur usage de mon temps.
D'ailleurs, à l'époque, Apple (ils sont revenus plusieurs fois dans la discussion comme symbole de qualité... lol) n'avait pas encore eu son goto-fail, et j'avais, justement, déjà réglé mon compilo et mon style de codage pour rendre ce bug entièrement impossible. Sans écrire le moindre test.
Après, je sais que le sujet du journal est lié aux tests d'UI, mais la discussion ici me semble avoir assez dérivé, donc ce commentaire n'est pas trop à côté de la plaque j'espère?