mes années d'expérience en développement logiciel suggèrent qu'en pratique cela ne peut pas fonctionner.
L'as tu essayé? Dave et moi avons écrit le livre sur la base de nombreuses années d'expérience collective, à la fois de nous-mêmes et d'autres personnes âgées de ThoughtWorks, en train de faire les choses dont nous discutons. Rien dans le livre n'est spéculatif. Tout ce dont nous discutons a été testé et testé même sur de grands projets distribués. Mais nous ne vous suggérons pas de le croire. Bien sûr, vous devriez l'essayer vous-même, et veuillez écrire ce que vous trouvez qui fonctionne et ce qui ne fonctionne pas, y compris le contexte pertinent, afin que d'autres puissent apprendre de vos expériences.
La livraison continue met l'accent sur les tests automatisés. Nous passons environ 1/3 du livre à en parler. Nous le faisons parce que l'alternative - les tests manuels - est coûteuse et sujette aux erreurs, et n'est en fait pas un excellent moyen de créer un logiciel de haute qualité (comme l'a dit Deming, «Cesser de dépendre de l'inspection de masse pour atteindre la qualité. Améliorer le processus et renforcer la qualité dans le produit en premier lieu ")
Une couverture complète du test est impossible. Vous devez consacrer beaucoup de temps - et le temps c'est de l'argent - pour chaque petite chose. C'est précieux, mais le temps pourrait être consacré à contribuer à la qualité par d'autres moyens.
Bien sûr, une couverture de test complète est impossible, mais quelle est l'alternative: une couverture de test zéro? Il y a un compromis. Quelque part entre les deux se trouve la bonne réponse pour votre projet. Nous constatons qu'en général, vous devez vous attendre à passer environ 50% de votre temps à créer ou à maintenir des tests automatisés. Cela peut sembler coûteux jusqu'à ce que vous considériez le coût des tests manuels complets et de la correction des bogues qui sortent pour les utilisateurs.
Certaines choses sont difficiles à tester automatiquement. Par exemple, GUI. Même Selenium ne vous dira pas si votre interface graphique est bancale.
Bien sûr. Découvrez le quadrant de test de Brian Marick. Vous devez toujours effectuer des tests exploratoires et des tests d'utilisabilité manuellement. Mais c'est pour cela que vous devriez utiliser vos êtres humains chers et précieux - pas pour les tests de régression. La clé est que vous devez mettre en place un pipeline de déploiement afin de ne prendre la peine d'exécuter que des validations manuelles coûteuses sur des builds qui ont réussi une suite complète de tests automatisés. Ainsi, vous réduisez à la fois le montant d'argent que vous dépensez pour les tests manuels et le nombre de bogues qui parviennent jamais à un test manuel ou à une production (délai auquel ils sont très coûteux à corriger). Les tests automatisés effectués correctement sont beaucoup moins chers sur la durée de vie du produit, mais bien sûr, il s'agit d'une dépense en capital qui s'amortit avec le temps.
L'accès à la base de données est difficile à tester sans appareils encombrants, et même cela ne couvrira pas les cas étranges dans votre stockage de données. De même la sécurité et bien d'autres choses. Seul le code de la couche métier est effectivement testable à l'unité.
L'accès à la base de données est testé implicitement par vos tests d'acceptation fonctionnelle basés sur des scénarios de bout en bout. La sécurité nécessitera une combinaison de tests automatisés et manuels - tests de pénétration automatisés et analyse statique pour trouver (par exemple) des dépassements de tampon.
Même dans la couche métier, la plupart des codes ne sont pas des fonctions simples dont les arguments et les valeurs de retour peuvent être facilement isolés à des fins de test. Vous pouvez passer beaucoup de temps à créer des objets fictifs, ce qui pourrait ne pas correspondre aux implémentations réelles.
Bien sûr, les tests automatisés sont chers si vous construisez mal votre logiciel et vos tests. Je recommande fortement de consulter le livre "Un logiciel orienté objet en pleine croissance, guidé par des tests" pour comprendre comment le faire correctement afin que vos tests et votre code soient maintenables dans le temps.
Les tests d'intégration / fonctionnels complètent les tests unitaires, mais leur exécution prend beaucoup de temps car ils impliquent généralement la réinitialisation de l'ensemble du système à chaque test. (Si vous ne réinitialisez pas, l'environnement de test est incohérent.)
L'un des produits sur lesquels je travaillais a une suite de 3 500 tests d'acceptation de bout en bout qui prennent 18 heures pour s'exécuter. Nous l'exécutons en parallèle sur une grille de 70 cases et obtenons un retour sur 45m. Encore plus longtemps que l'idéal, c'est pourquoi nous l'exécutons en tant que deuxième étape du pipeline après que les tests unitaires se soient déroulés en quelques minutes afin de ne pas gaspiller nos ressources sur une construction dont nous n'avons pas un niveau de base confiance en.
La refactorisation ou tout autre changement casse de nombreux tests. Vous passez beaucoup de temps à les réparer. S'il s'agit de valider des modifications de spécifications significatives, c'est bien, mais les tests échouent souvent en raison de détails d'implémentation de bas niveau sans signification, pas de choses qui fournissent vraiment des informations importantes. Souvent, le peaufinage vise à retravailler les éléments internes du test, et non à vérifier réellement les fonctionnalités testées.
Si votre code et vos tests sont bien encapsulés et faiblement couplés, le refactoring ne cassera pas beaucoup de tests. Nous décrivons dans notre livre comment faire la même chose pour les tests fonctionnels aussi. Si vos tests d'acceptation échouent, c'est un signe que vous manquez un ou plusieurs tests unitaires, donc une partie du CD implique d'améliorer constamment votre couverture de test pour essayer de trouver des bogues plus tôt dans le processus de livraison où les tests sont plus fins et les les bogues sont moins chers à corriger.
Les rapports de terrain sur les bogues ne peuvent pas être facilement mis en correspondance avec la micro-version précise du code.
Si vous testez et publiez plus fréquemment (une partie de l'intérêt du CD), il est relativement simple d'identifier le changement qui a causé le bogue. L'intérêt du CD est d'optimiser le cycle de rétroaction afin que vous puissiez identifier les bogues dès que possible après leur archivage au contrôle de version - et en fait, de préférence avant leur archivage (c'est pourquoi nous exécutons les tests de construction et unitaires avant l'enregistrement).