How To Write Better Tests In 6 Easy Steps

Summary

Ce script d'une vidéo traite de la difficulté de rédaction de tests de code et de la manière de les améliorer. Kyle, de Web Dev Simplified, explique les bonnes pratiques pour écrire des tests de qualité, y compris le respect de la règle d'or des assertions, l'évitement des tests instables et la minimisation des détails d'implémentation dans les tests. Il recommande l'utilisation de techniques telles que la substitution de fonctions (mocking) pour les appels réseau ou bases de données, et suggère un équilibre entre les tests unitaires, d'intégration et de bout en bout pour garantir la fiabilité de l'application.

Takeaways

• 📝 L'écriture de tests pour votre code est difficile, mais encore plus difficile de bien les écrire.
• 🔍 Il est important d'écrire des tests de qualité qui ne échouent que si le code est incorrect.
• 📉 Les tests doivent être stables et ne pas être capricieux ou échouer parfois sans raison apparente.
• 🛠️ Il est préférable d'éviter de tester les détails d'implémentation et de considérer le code comme une boîte noire.
• 🔄 Il est conseillé de mocker les appels externes tels que les requêtes réseau ou bases de données pour des tests unitaires ou d'intégration.
• 🚫 Il est essentiel d'éviter les tests qui échouent de manière intermittente, car ils sapent la confiance dans le processus de test.
• 💡 L'écriture de tests en suivant les principes du développement piloté par les tests (TDD) peut aider à éviter les détails d'implémentation.
• 🔄 Il est acceptable de répéter le code dans les tests pour assurer leur indépendance mutuelle.
• 📈 Les tests d'intégration et les tests de bout en bout sont préférables aux tests unitaires pour garantir que l'application fonctionne de manière globale.
• 🔍 Un bon équilibre entre les différents types de tests est nécessaire pour assurer la qualité globale du code.

Q & A

Pourquoi écrire des tests pour son code est-il difficile ?

Écrire des tests pour son code est difficile car il faut s'assurer que ces tests sont de haute qualité et qu'ils ne défaillent pas même lorsqu'ils ne devraient pas, c'est-à-dire qu'ils ne doivent échouer que si le code est incorrect.

Quel est le 'règle d'or des assertions' mentionné dans la vidéo ?

La règle d'or des assertions signifie que les tests ne doivent échouer que si le code est incorrect et non fonctionnel. Il ne devrait pas y avoir de tests instables qui échouent parfois ou des tests qui échouent lorsqu'on modifie le code même si celui-ci fonctionne toujours correctement.

Quels sont les types de tests discutés dans la vidéo ?

La vidéo parle de tests unitaires, de tests d'intégration, de tests de bout en bout et d'autres types de tests.

Pourquoi est-il important de ne pas tester les détails d'implémentation dans ses tests ?

Tester les détails d'implémentation rend les tests fragiles et compliqués à écrire. Si les détails d'implémentation changent, les tests échoueront même si le code fonctionne toujours correctement.

Que signifie 'ne pas se soucier des détails d'implémentation' dans le contexte des tests ?

Cela signifie de considérer le code testé comme une boîte noire et de se concentrer uniquement sur les entrées et les sorties attendues, sans se soucier de la manière dont le code produit ces résultats.

Quels sont les avantages de la 'déshydratation' (DRY) dans le développement de logiciels ?

La déshydratation évite la répétition de code et favorise la lisibilité et la maintenance. Cependant, dans le contexte des tests, il est parfois préférable de répéter le code plutôt que de partager un code de configuration qui pourrait affecter plusieurs tests en cas de modification.

Pourquoi faut-il éviter les tests qui échouent de manière intermittente ?

Les tests qui échouent de manière intermittente sont frustrants car ils donnent des résultats non fiables et faussent la confiance dans le processus de test. Si un test échoue parfois et pas d'autres, il devient difficile de savoir si le code est réellement en erreur ou si le test est mal écrit.

Quelle est la différence entre un test unitaire, un test d'intégration et un test de bout en bout ?

Un test unitaire teste une seule fonction ou un morceau de code. Un test d'intégration teste si plusieurs parties d'une application fonctionnent bien ensemble. Un test de bout en bout teste l'application dans son ensemble, comme un utilisateur le ferait, en utilisant par exemple un navigateur.

Quels sont les avantages de la pratique du développement piloté par les tests (TDD) ?

Le développement piloté par les tests force à écrire les tests avant le code, ce qui évite d'inclure des détails d'implémentation dans les tests et se concentre sur les résultats attendus pour des entrées données.

Quelle est la recommandation finale de Kyle sur la façon d'écrire des tests de haute qualité ?

Kyle recommande de ne pas tester les détails d'implémentation, d'éviter les tests qui échouent de manière intermittente, de répéter le code dans les tests pour s'assurer que chaque test soit autosuffisant, et de trouver un bon équilibre entre les tests unitaires, d'intégration et de bout en bout.