đ§Ș RĂ©diger un test automatisĂ© prend 20 fois plus de temps que de vĂ©rifier la mĂȘme chose Ă la main, en moyenne. Câest pour cela que les prototypes et autres logiciels âone shotâ ne sont pas accompagnĂ©s de cas de test. 20 fois ça nâest pas grand chose, surtout avec des mĂ©thodes comme TDD oĂč les tests sont exĂ©cutĂ©s plusieurs fois par heure.
đș Il y a tout de mĂȘme un loup : si les tests automatisĂ©s doivent ĂȘtre refaits en permanence Ă cause dâune technique inadaptĂ©e, lâaddition peut ĂȘtre bien plus salĂ©e. Câest lĂ que le bĂąt blesse dans de nombreuses entreprises. Des tests fragiles, trop couplĂ©s Ă une implĂ©mentation (tests unitaires par exemple) ou mal fichus auront trĂšs peu dâintĂ©rĂȘt Ă©conomique par rapport Ă des tests manuels.
đ Pour savoir comment tester correctement, lâindustrie et la recherche doivent communiquer. Ca nâest absolument pas le cas. La recherche tourne en vase clos sur des hypothĂšses qui nâintĂ©ressent pas les praticiens. Ces derniers ne lisent pas les travaux des chercheurs, ce qui leur permettrait de valider les hypothĂšses des gourous Ă la mode. Lâauteur de cette thĂšse met le doigt sur ce qui mâa fait dĂ©marrer cette entreprise de vulgarisation. Notre profession doit marcher sur deux jambes pour cesser de claudiquer : lâexpertise des maĂźtres et le savoir des chercheurs.
SOURCE
Kemppainen, Toni, The benefits of Test Automation in Software Development (2022)
Enzo Sandré
đ Lien public