Avis des lecteurs
Résumé:Les critiques de « Design Driven Testing : Test Smarter, Not Harder » sont mitigées, certains lecteurs louant ses idées sur la méthodologie de test et d'autres lui reprochant d'être une attaque tendancieuse contre le développement piloté par les tests (TDD). Alors que certains trouvent que le livre est une ressource utile qui apporte clarté et exemples pratiques, d'autres estiment qu'il manque de substance, qu'il fait la promotion des autres travaux des auteurs et qu'il contient des inexactitudes sur le développement piloté par les tests (TDD).
Avantages:Les lecteurs ont apprécié la nouvelle perspective du livre sur les méthodologies de test, en particulier l'accent mis sur les tests pilotés par la conception (DDT) par rapport au développement traditionnel piloté par les tests (TDD). Le style d'écriture est noté comme étant clair et concis, avec des exemples pratiques qui aident à comprendre les concepts. Certains ont trouvé qu'il s'agissait d'une ressource utile pour améliorer les techniques de test dans le développement de logiciels.
Inconvénients:Les critiques soutiennent que le livre rejette le TDD sans le comprendre correctement et qu'il est rempli d'inexactitudes sur les méthodologies agiles. Certains ont trouvé qu'il s'agissait de matériel promotionnel pour les propres produits des auteurs, en particulier ICONIX, plutôt que d'une exploration juste de la DDT. En outre, le livre suppose une certaine familiarité avec certains outils et travaux antérieurs, ce qui peut limiter son accessibilité à un public plus large. Plusieurs critiques ont décrit le contenu comme étant répétitif et aride.
(basé sur 11 avis de lecteurs)
Titre original :
Design Driven Testing: Test Smarter, Not Harder
Contenu du livre :
Dans ce chapitre, nous avons illustré comment conduire des tests unitaires à partir de la conception d'un logiciel, en identifiant les scénarios de test de manière systématique afin de s'assurer que le code est couvert à tous les bons endroits. Nous avons également illustré l'utilisation de "stunt services" et d'objets fictifs pour isoler le code testé ; enfin, nous avons discuté de l'exécution de tests unitaires plus profondément dans le code algorithmique qui peut bénéficier de tests plus fins.
Existe-t-il un moyen d'obtenir 95 % des avantages des tests unitaires complets que nous avons effectués dans ce chapitre avec beaucoup moins de tests ? Dans le chapitre suivant, nous montrerons comment faire exactement cela avec les tests de contrôleur. Comme vous le verrez, les tests unitaires ont leur place, mais les tests de contrôleur peuvent souvent représenter une approche plus intelligente et plus structurée des tests d'application. 136 C H A P I T R E 6 ? ??? Conception et test du contrôleur Comme vous l'avez vu au chapitre 5, les tests unitaires ne doivent pas nécessairement couvrir chaque ligne de code, ou même chaque méthode, avec des tests.
Il existe une loi des rendements décroissants - et une difficulté croissante - au fur et à mesure que l'on augmente le percentile de couverture du code. En prenant du recul et en examinant la conception à une échelle plus large, il est possible d'identifier les zones clés du code qui agissent comme des jonctions d'entrée/sortie, et de concentrer les tests sur ces zones.
Autres informations sur le livre :
| ISBN : | 9781430229438 |
| Auteur : | |
| Éditeur : | |
| Langue : | anglais |
| Reliure : | Broché |
Achat:
Actuellement disponible, en stock.
