Cr\u00e9ez des tests fonctionnels automatis\u00e9s au sein de vos suites, qui ex\u00e9cuteront automatiquement les cas de test. Utilisez cette m\u00e9thode dans le cadre de votre programme d’assurance qualit\u00e9 (QA) pour d\u00e9couvrir et corriger les bugs avant la mise en production de votre application.<\/div>\r\n <\/div>\r\n\n\n\n
Pourquoi vous devriez \u00e9viter les tests manuels et ce qu’il faut faire \u00e0 la place<\/h2>\n\n\n\n
\u00c0 l’oppos\u00e9 des tests fonctionnels, on trouve les tests manuels. Les tests manuels sont un type de test logiciel dans lequel les cas de test sont ex\u00e9cut\u00e9s manuellement par une personne charg\u00e9e des tests, sans utiliser d’outils automatis\u00e9s. Vous devriez toujours privil\u00e9gier les tests fonctionnels par rapport aux tests manuels, car un test manuel est sujet aux erreurs et n’est pas reproductible.<\/p>\n\n\n\n
De nombreuses personnes en programmation font l’erreur d’ex\u00e9cuter un service localement et de tester manuellement les points de terminaison pour diagnostiquer des probl\u00e8mes. L’ayant fait pendant de nombreuses ann\u00e9es, nous ne comptons plus le nombre de fois o\u00f9 nous avons reproduit un probl\u00e8me sans savoir exactement comment nous avions proc\u00e9d\u00e9, ce qui a provoqu\u00e9 des envies de tout envoyer balader en essayant de retracer nos pas.<\/p>\n\n\n\n
Les sessions de d\u00e9bogage passent souvent de quelques heures \u00e0 plusieurs jours, et avec les tests manuels, tous les sc\u00e9narios que nous essayons ne sont pas document\u00e9s et finissent par se confondre. Cependant, si tous ces sc\u00e9narios tent\u00e9s sont r\u00e9dig\u00e9s sous forme de tests fonctionnels<\/b>, chaque sc\u00e9nario peut devenir une partie de l’historique de la session de d\u00e9bogage.<\/p>\n\n\n \r\n\r\n
Si vous \u00e9crivez des tests fonctionnels pour de nouveaux sc\u00e9narios, ils peuvent \u00eatre int\u00e9gr\u00e9s \u00e0 la suite de tests de r\u00e9gression ex\u00e9cut\u00e9e pendant l’int\u00e9gration continue (CI).<\/div>\r\n <\/div>\r\n\n\n\n
Il y a un secret concernant les tests fonctionnels. L’\u00e9criture de tests fonctionnels pour diagnostiquer les probl\u00e8mes est une strat\u00e9gie cl\u00e9 pour minimiser le temps de r\u00e9solution des bugs. Toutefois, cette m\u00e9thode de diagnostic ne fonctionne pas si l’\u00e9criture du test fonctionnel s’av\u00e8re difficile. La solution\u00a0? Simplifiez les choses d\u00e8s la premi\u00e8re \u00e9tape.<\/p>\n\n\n\n
Cr\u00e9ez une suite de fonctions utilitaires et d’assertions simples.<\/b> Le but est de rendre les actions, telles que les boucles de relance et le fait d’importer des suites de donn\u00e9es, TR\u00c8S faciles \u00e0 r\u00e9aliser. Ces fonctions utilitaires devraient figurer parmi les premiers outils cr\u00e9\u00e9s lors de l’\u00e9criture initiale du logiciel pour servir de support aux nouveaux tests fonctionnels par la suite.<\/p>\n\n\n\nUn exemple\u00a0: comment nous avons fait cela chez Mailgun<\/h3>\n\n\n\n
L’API \/messages principale chez Mailgun est g\u00e9r\u00e9e par un service que nous appelons influx. Ce service ing\u00e8re \u00e0 la fois les messages HTTP et SMTP dans notre syst\u00e8me et communique avec presque tous les autres services de notre suite de services d’envoi de messages.<\/p>\n\n\n\n
En cons\u00e9quence, nous avons lourdement investi dans notre suite de tests fonctionnels et avons mod\u00e9lis\u00e9 notre environnement de production dans le code pour cette partie tr\u00e8s publique de notre catalogue de services. Nous avons cr\u00e9\u00e9 plus de 700\u00a0tests, dont la plupart sont fonctionnels et s’ex\u00e9cutent en six minutes environ sur une machine locale.<\/p>\n\n\n\n
Bon nombre de ces tests ont \u00e9t\u00e9 ajout\u00e9s au cours de sessions de d\u00e9bogage ou de diagnostic, puis ont \u00e9t\u00e9 int\u00e9gr\u00e9s \u00e0 notre suite de tests. Si un nouveau sc\u00e9nario s’av\u00e8re n\u00e9cessaire, il est ajout\u00e9 \u00e0 la suite fonctionnelle et constitue une protection contre les futures r\u00e9gressions.<\/p>\n\n\n\n
Derni\u00e8res remarques<\/h2>\n\n\n\n
Le v\u00e9ritable co\u00fbt du d\u00e9veloppement logiciel r\u00e9side dans la maintenance et le diagnostic du code. C’est pourquoi se donner les moyens de r\u00e9ussir, en cr\u00e9ant une suite d’outils utilisable pour r\u00e9duire le temps de r\u00e9solution, justifie cet investissement suppl\u00e9mentaire en temps et en argent.<\/p>\n\n\n\n
Cet investissement initial continuera de porter ses fruits tout au long de la dur\u00e9e du projet.<\/p>\n\n\n\n
Avez-vous appr\u00e9ci\u00e9 notre point de vue sur la recherche et le diagnostic des bugs informatiques\u00a0? Si vous souhaitez davantage de contenus de ce type, n’oubliez pas de vous inscrire \u00e0 notre newsletter.<\/p>\n\n\n