trouver un expert Python
Parfois appelé Test First Development, Test First Programming est un beau concept qui a radicalement changé ma façon d'aborder le développement de logiciels.
Les idées de Testez d'abord la programmation et Développement piloté par les tests sont souvent confus.
cependant, Tester d'abord est assez puissant pour être autonome.
Je pense qu’il est important de présenter les concepts séparément.
TDD et de nombreuses autres pratiques agiles s'appuient sur Tester d'abord.
Il ne s’agit pas seulement de rappeler le passé.
Les leçons apprises de Tester d'abord sont toujours très importants.
Voici ce que je vais couvrir dans cet article:
Concept simple
Au fond, l’idée est très simple.
Ecrivez les tests avant d’écrire le code.
C’est vraiment ça.
J’ai déjà vu les étapes de l’écriture de quelque chose comme ceci:
- Écrire la spécification
- Ecrire les tests au cahier des charges
- Écrivez le code jusqu'à ce que tous les tests passent
C’est essentiellement ça.
Mais je ne trouve pas ces 3 étapes utiles pour me dire réellement comment le faire.
La partie suivante présentera les étapes d’une manière que j’estime utile pour que le travail soit réellement accompli.
Après cela, je parlerai un peu de la raison pour laquelle le test d’abord est une bonne idée.
Étapes pour Testez d'abord la programmation
- Pensez à ce que vous voulez faire.
- Pensez à quoi cela ressemble du point de vue des clients, y compris l’API.
- Pensez à la façon de le tester.
- Ecrire les cas de test de chemin heureux.
- Écrivez le code de production.
- Développez les tests pour une couverture plus complète du comportement.
- Ecrivez le code de production pour réussir les tests.
Chacune de celles-ci est beaucoup plus complexe que ne l'indique la seule ligne.
Chacune de ces opérations est effectuée sur chaque fonctionnalité, chaque changement de comportement, chaque correctif.
Les étapes sont en ordre. C'est une progression.
Il y a aussi des boucles, des itérations, des revisites.
Le parallélisme est également possible pour certaines étapes, et bienvenu.
Plus sur ce que je parle de chaque étape.
Étapes élargies
1. Pensez à ce que vous voulez faire.
Recueillir les exigences.
Définir la fonctionnalité.
Essayez de comprendre quel problème client la fonctionnalité résout.
Quelles sont les véritables exigences fondamentales pour résoudre le problème?
Les fonctionnalités s'étendent souvent au fur et à mesure que le développement progresse.
Le moment est venu de définir la portée minimale viable de cette fonctionnalité.
Si d'autres ont leur mot à dire sur les extensions de la fonctionnalité, ou "ce serait bien si", c'est génial. Allez-y et capturez ces idées.
Mais la première itération devrait s'en tenir à une portée minimale. Vous pouvez développer de manière itérative une fois que vous avez un produit qui peut être vendu.
2. Réfléchissez à ce à quoi cela ressemble du point de vue du client, y compris l’API.
API
- À quoi ressemblera l’API?
- Cela résout-il le problème du client?
- Est-ce propre?
- Est-ce gênant?
- Pouvez-vous imaginer l'utiliser?
- Est-ce facile à expliquer?
Interface graphique
- A quoi ça va ressembler?
- Quels sont les éléments d'entrée nécessaires?
- Sont-ils vraiment nécessaires?
- Est-il raisonnable pour l'utilisateur de connaître les informations que vous demandez?
C'est le moment idéal pour faire appel à un ingénieur en ergonomie si vous en avez un.
Dites à quelqu'un comment verbalement quel est le but de la fonctionnalité, comment l'utiliser et ce qu'elle devrait voir.
Écoutez leurs questions et leurs commentaires.
Tu veux changer quelque chose après tout ça?
C’est le moment le plus facile de changer, car il n’existe pas encore de code de production.
3. Réfléchissez à la façon de le tester.
- Comment savons-nous si la fonctionnalité fonctionne?
- Comment savons-nous si cela ne fonctionne pas?
- Qu'est-ce qui peut aller mal? Pouvons-nous vérifier cela?
- Quelle est la partie critique de la fonction? Comment cela peut-il être testé?
- Manque-t-il une API pour permettre aux tests automatisés d'interroger le système à la recherche de conditions d'erreur?
- Quelle est la partie la plus risquée de la fonctionnalité? Comment cela peut-il être testé?
Pour les fonctionnalités complexes, cette étape peut être quelque chose de semi-formel.
Notez les informations recueillies aux étapes 1 à 3.
Distribuez-le aux personnes qui pourraient avoir une bonne contribution.
Ou faites ceci comme une réunion rapide si vous avez toutes les personnes appropriées en un seul endroit.
4. Ecrivez les cas de test Happy Path.
L'écriture des tests vous permet d'utiliser l'API.
Si l'API est lourde, les tests seront difficiles à écrire. Si c'est le cas, changez l'API. Rendez-le plus facile à utiliser.
Ecrivez suffisamment de tests pour satisfaire les critères suivants:
- La fonctionnalité complète est testée de la manière dont un client l’utiliserait.
- Chaque fonction de l'API est utilisée par au moins un test.
Reste-t-il des fonctions que vous n’avez pas eu besoin d’utiliser? Pouvez-vous supprimer cette fonction API sans limiter l'utilisateur? Alors fais-le.
Notez les éléments que vous devez tester et qui n’ont pas été capturés à l’étape 3.
5. Écrivez le code de production.
Ecrivez le code de production pour réussir un test.
Continuez jusqu'à ce que tous les tests passent.
Si votre infrastructure de test prend en charge xfail, vous pouvez marquer tous les tests comme xfail en premier et supprimer la marque un à la fois.
Notez les éléments que vous devez tester et qui n’ont pas été capturés aux étapes 3 ou 4.
Prenez note des fonctionnalités que vous souhaitez ajouter mais ne sont pas nécessaires pour réussir les tests. Il est naturel de vouloir ajouter des cloches et des sifflets. Ne le fais pas maintenant. Capturez les idées quelque part et laissez-les comme une itération future une fois la fonctionnalité minimale terminée. Ensuite, vous pouvez hiérarchiser ces idées avec le reste des idées d’extension de fonctionnalités.
6. Développez les tests pour une couverture plus complète du comportement.
Regardez l'ensemble des tests que vous avez, la fonctionnalité, l'API.
Soyez aussi complet que vous le pouvez.
Existe-t-il des conditions d'erreur qui n'ont pas encore été testées?
Assurez-vous que les éléments critiques de la mission et de la zone à risque identifiés à l'étape 3 ont été entièrement testés.
Beaucoup de ces nouveaux tests vont passer. Génial. Cependant, cela devient difficile pour vous assurer que vous testez réellement le code.
Certaines personnes, comme saboter le code pour faire le test, ne parviennent pas à s'assurer qu'ils savent que le test fonctionne.
Bien sûr, certains des nouveaux tests échoueront. Aussi super. Vous avez découvert une faiblesse dans votre code.
Consacrez le temps nécessaire à cela. Et puis continue.
Je sais que c'est vague. Mais le temps passé sur ceci est "ça dépend".
Si la fonctionnalité est petite et n'est pas cruciale pour le succès de votre produit, le sur-tester est une perte de temps.
Si cette fonctionnalité est la fonctionnalité la plus importante de votre produit qu'aucun autre concurrent ne peut réaliser, testez-la.
Cette étape est vraiment difficile à obtenir.
L'écriture de test et la conception de cas de test sont un peu une forme d'art.
Je vais écrire sur une théorie et une stratégie de conception de cas de test dans un prochain article.
7. Ecrivez le code de production pour réussir les tests.
Assez explicite. Allez réparer le code.
Pourquoi Tester d'abord?
Il est indéniable que pour les logiciels complexes, qu’il s’agisse ou non de TDD ou Tester d'abord est utilisé, des tests approfondis sont indispensables avant de pouvoir appeler votre logiciel terminé.
Vous pouvez écrire les tests après avoir écrit le code.
Mais il y a vraiment de bonnes raisons d'écrire les tests en premier.
- Vous pouvez utiliser les tests pour vous guider dans le code à suivre.
- Vous pouvez utiliser les tests pour vous avertir lorsque vous avez fini de coder et éviter le glissement de fonctionnalités.
- Si c’est la même personne qui écrit les tests et le code de production, alors les hypothèses que vous avez faites en écrivant le code coloreront la façon dont vous écrivez les tests et vous manquerez de façons d’utiliser votre code. Écrire les tests avant d’écrire le code atténuera quelque peu cette situation.
- Réfléchir et rédiger des tests vous aide à comprendre les spécifications.
- Les parties encombrantes de l'API peuvent être corrigées avant sa mise en œuvre.
- Les trous et les incohérences dans la spécification sont découverts tôt.
- Les tests seront écrits. Si vous retardez les tests jusqu'à ce que votre code soit «terminé», il existe une chance raisonnable que vous envoyiez ce code avant que les tests ne soient terminés. Et ensuite, vos clients trouveront les bogues que vos tests pourraient avoir détectés.
Être honnête. Vous allez faire des tests pour vous assurer que votre code fonctionne quand même. Pourquoi ne pas simplement écrire les tests fonctionnels en premier et les utiliser pour vous aider à développer et à déboguer votre code pendant que vous l'écrivez.
Lignes floues entre TDD et Tester d'abord
Cette description ressemble beaucoup à Développement piloté par les tests. Je pense que la ligne est floue.
Et pour être honnête, ma version de TDD ressemble à ce qui est présenté ici plus proche de certaines versions de TDD.
Je vais écrire sur beaucoup de saveurs de TDD dans les prochains articles, y compris une description de ce que j’utilise comme TDD.
Et ensuite, je vais essayer de ne pas oublier de les comparer.
Comme toujours, laissez-moi savoir ce que vous pensez et restez en contact. J'aime recevoir des emails.
Messages de soutien comme celui-ci.
Si cela vous a aidé, montrez votre soutien:
[ad_2]