Tu te trompes. Je ne fais pas cette affirmation. Je réponds à la tienne (il faut pouvoir changer), sous-entendant donc que le choix initial est mauvais.
Non, un bon choix à un moment donné n'a pas de raison de le rester.
Les tests unitaires n'ont jamais remplacé les tests d'intégration.
Oui mais c'est précisément l'inverse dont il est question : tester du fonctionnel via des tests d'intégration. Les tests d'intégrations sont longs par nature, c'est pour cela qu'ils couvrent moins (et aussi parce qu'ils font exploser la combinatoire).
Je ne dis pas qu'il ne faut pas faire de test d'intégration, je dis que c'est dommageable d'essayer de tester le métier par des tests d'intégration.
Il faut anticiper au maximum.
C'est un bon moyen de se planter. Parce que je doute que tu sois meilleur devint que moi. Ton client non plus, lui refourguer cette responsabilité ne change rien au problème (ça change juste la responsabilité). C'est le principe même de l'over-engenering imaginer beaucoup et surtout beaucoup trop.
Au contraire réduire ton scope de décision au minimum et remettre à plus tard tout ce qui peut l'être jusqu'à être assez mûre pour choisir. Ce que tu propose est typiquement le cycle en V dans le quel les erreurs sont très chères ! (à tous point de vu)
Avoir plus de tests, oui. Il faut les écrire !
Ça dépend de ce que tu entends par livrer. Si on entend par là, la livraison où l'utilisateur est satisfait de sa fonctionnalité, les tests ne coûtent rien. Ils ne coûtent rien face au temps que te coûte un bug dans la livraison et que la perte de confiance de l'utilisateur envers ton logiciel.
Et pour ma part, les feedbacks, ce ne sont pas les tests qui me les donnent, mais les utilisateurs.
Ça n'a rien avoir. Il s'agit lors de ton développement du temps que tu as entre l'écriture d'une ligne et la vérification qu'elle fait ce que veux. C'est le cycle (dans la majorité des cas) :
écriture
compilation
exécution
retour à l'étape 1
Si ton exécution c'est des tests, tu vérifie plus rapide l'ensemble de test cas que. Si tu le fais manuellement, tu n'aura tendance à vérifier que le cas que tu es entrain de traiter (en oubliant éventuellement les cas qui sont impactés) et tu perd du temps à revenir dans l'état qui te correspond. Si tu attends que le client t'envoie un mail, euh... comment dire... :)
Sauf que tu fais tout cela justement pour ne pas être lié à une technologie sous-jacente. Ainsi, ton choix (pertinent) d'aujourd'hui peut être une véritable plaie quand tu devras changer de techno demain.
Ton métier évolue généralement peu. L'abstraction devrait donc rester pertinente. Cette abstraction n'est pas quelque chose qui est artificiel, elle est dépendante de ton métier. Donc elle ne doit pas être remise en cause par la technologie, mais par le métier (c'est l'idée à travers l'inversion de dépendance). Si ça devient une plaie, c'est soit que tu as mal conçu ton abstraction (ça arrive) soit que tu dois remettre en cause ta techno.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Non, un bon choix à un moment donné n'a pas de raison de le rester.
Oui mais c'est précisément l'inverse dont il est question : tester du fonctionnel via des tests d'intégration. Les tests d'intégrations sont longs par nature, c'est pour cela qu'ils couvrent moins (et aussi parce qu'ils font exploser la combinatoire).
Je ne dis pas qu'il ne faut pas faire de test d'intégration, je dis que c'est dommageable d'essayer de tester le métier par des tests d'intégration.
C'est un bon moyen de se planter. Parce que je doute que tu sois meilleur devint que moi. Ton client non plus, lui refourguer cette responsabilité ne change rien au problème (ça change juste la responsabilité). C'est le principe même de l'over-engenering imaginer beaucoup et surtout beaucoup trop.
Au contraire réduire ton scope de décision au minimum et remettre à plus tard tout ce qui peut l'être jusqu'à être assez mûre pour choisir. Ce que tu propose est typiquement le cycle en V dans le quel les erreurs sont très chères ! (à tous point de vu)
Ça dépend de ce que tu entends par livrer. Si on entend par là, la livraison où l'utilisateur est satisfait de sa fonctionnalité, les tests ne coûtent rien. Ils ne coûtent rien face au temps que te coûte un bug dans la livraison et que la perte de confiance de l'utilisateur envers ton logiciel.
Ça n'a rien avoir. Il s'agit lors de ton développement du temps que tu as entre l'écriture d'une ligne et la vérification qu'elle fait ce que veux. C'est le cycle (dans la majorité des cas) :
Si ton exécution c'est des tests, tu vérifie plus rapide l'ensemble de test cas que. Si tu le fais manuellement, tu n'aura tendance à vérifier que le cas que tu es entrain de traiter (en oubliant éventuellement les cas qui sont impactés) et tu perd du temps à revenir dans l'état qui te correspond. Si tu attends que le client t'envoie un mail, euh... comment dire... :)
Ton métier évolue généralement peu. L'abstraction devrait donc rester pertinente. Cette abstraction n'est pas quelque chose qui est artificiel, elle est dépendante de ton métier. Donc elle ne doit pas être remise en cause par la technologie, mais par le métier (c'est l'idée à travers l'inversion de dépendance). Si ça devient une plaie, c'est soit que tu as mal conçu ton abstraction (ça arrive) soit que tu dois remettre en cause ta techno.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)