Quels sont les inconvénients de l'écriture de code avant d'écrire des tests unitaires?

J'ai toujours vu la recommandation selon laquelle nous devrions d'abord écrire des tests unitaires, puis commencer à écrire du code. Mais j'estime qu'il est beaucoup plus confortable de procéder dans l'autre sens - écrire du code puis des tests unitaires, car j'estime que nous avons beaucoup plus de clarté après avoir écrit le code lui-même. Si j'écris le code et ensuite les tests, il se peut que je doive changer un peu mon code pour le rendre testable, même si je me concentre beaucoup sur la création d'un design testable. Par contre, si j’écris les tests puis le code, ceux-ci changeront assez souvent au fur et à mesure que le code se modifie.

Comme je vois beaucoup de recommandations pour commencer à écrire des tests et ensuite passer au codage, quels sont les inconvénients si je le fais dans l'autre sens - écrire du code puis des tests unitaires?

Le rouge est la réponse. Le rouge est ce que vous obtenez du cycle de refactorisation rouge-vert de TDD que vous ne pouvez obtenir, testez-le en dernier. Commencez par écrire un test qui échoue. Regardez-le échouer. C'est ton rouge, et c'est important. Il dit: J'ai cette exigence et je sais que mon code ne la satisfait pas. Ainsi, lorsque vous passez à l’étape 2 (verte), vous savez avec la même certitude que votre code satisfait à cette exigence. Vous savez que vous avez modifié votre base de code de manière à satisfaire à l'exigence.

Des exigences (tests) développées après le code, sur la base du code, vous privent de ce type de certitude, de confiance.

Si vous écrivez le code, puis les tests, il est trop facile de tomber dans le piège d'écrire les tests pour que le code soit réussi, plutôt que d'écrire les tests pour vous assurer que le code est conforme à la spécification.

Cela dit, ce n'est certainement pas la seule façon de faire les choses, et il n'y a pas de "meilleure" façon de développer des logiciels. Si vous mettez beaucoup de travail initial dans le développement de cas de test, vous ne saurez pas si votre architecture proposée présente des failles avant bien plus tard - alors que si vous développez le code en premier, vous les rencontrerez plus tôt et pourrez les redéfinir avec moins de fond. effort.

En fait, les gens qui ont du retard sur TDD, c'est une question de test, mais ils oublient les deux autres lettres de l'acronyme. Quelque chose qui peut être lu ici: TDD sans T ou TDD ne concerne pas les tests .

Le truc, c'est que j'ai appris une pléthore d'autres choses étroitement liées au TDD. Peu importe que vous testiez d'abord: Ce qui compte, c'est de penser à la conception de logiciels .

Pour pouvoir même écrire des tests unitaires "dans le bon sens", c'est-à-dire qu'ils soient isolés, rapides et automatisés, vous remarquerez qu'il est temps de repenser la manière dont votre code sera arrangé de manière à ce qu'il soit plus facile. tester.

Personnellement, j'ai appris moi-même les principes SOLID sans savoir qu'il y avait une telle chose écrite. En effet, l'écriture des tests unitaires m'a obligé à réécrire les classes afin qu'elles ne deviennent pas trop complexes à tester. Cela a conduit à des choses comme:

• Je devais déplacer des fonctionnalités qui n'avaient aucun sens, ou résider dans des méthodes privées, dans des classes séparées pour pouvoir les tester séparément. (Principe de responsabilité unique).
• Je devais éviter les grandes structures d'héritage et étendre les implémentations avec la composition (important dans le principe Open-Closed).
• Je devais être intelligent en matière d'héritage, j'utilisais des classes abstraites chaque fois que je voyais un code commun pouvant être partagé et utilisé avec des méthodes de stub (principe de substitution de Liskov).
• Je devais écrire des interfaces et des classes abstraites pour pouvoir tester les classes séparément. Ce qui vous amène par inadvertance à écrire des objets fictifs. (Principe de séparation des interfaces)
• Comme j'ai écrit beaucoup d'interfaces et de classes abstraites, j'ai commencé à déclarer des variables et des paramètres pour utiliser le type commun (principe d'inversion de dépendance).

Même si je ne fais pas de test tout le temps, je respecte les bons principes et pratiques OO que vous commencez à suivre, juste pour rendre les tests un peu plus faciles. Maintenant, je ne suis pas en train d'écrire du code pour lui-même. J'ai écrit du code afin qu'il puisse être facilement testé ou plus important encore; facilement entretenu .

Toutes les autres réponses sont bonnes, mais il y a un point qui n'a pas été abordé. Si vous écrivez le test en premier, il s'assure que les tests sont écrits. Il est tentant, une fois que vous avez écrit du code de travail, de sauter les tests et de simplement le vérifier via l'interface utilisateur. Si vous avez la discipline de toujours avoir un test qui échoue avant d'écrire du code, vous pouvez éviter ce piège.

Si vous écrivez vos tests en premier, cela vous donne une autre chance de penser à votre conception, avant que celle-ci ne soit "coulée dans le marbre".

Par exemple, vous pouvez penser que vous avez besoin d’une méthode prenant un certain ensemble de paramètres. Et si vous avez écrit le code en premier, vous l'écriviez de cette façon et ajustiez le test aux paramètres spécifiés. Mais si vous écrivez le test en premier, vous pourriez penser "attendez une minute, je ne voudrais pas utiliser ce paramètre dans le code principal, alors je devrais peut-être changer l'API".

Comme je vois beaucoup de recommandations pour commencer à écrire des tests et ensuite passer à la codification,

Il y a une vraie bonne raison à cela.

Si vous dites "fais ce qui te semble juste", les gens font les choses les plus stupides et les plus folles.

Si vous dites "écrivez d'abord les tests", les gens pourraient au moins essayer de faire ce qui est bien.

Quels sont les inconvénients si je le fais dans l'autre sens - écrire du code puis les tests unitaires?

Habituellement, un test moche et une conception qui doit être retravaillée pour pouvoir être testée.

Cependant, ce n'est qu'un "habituellement". Certaines personnes font évoluer les conceptions et les tests en parallèle. Certaines personnes mettent en place du code testable et écrivent des tests sans retouche.

La règle "Test First" est spécifiquement là pour enseigner et instruire des personnes qui n'ont aucune idée du tout.

De la même façon, on nous dit de toujours regarder dans les deux sens avant de traverser la rue. Cependant, nous ne le faisons pas réellement. Et ce n'est pas grave. Je vis dans un pays avec la conduite à droite et je n'ai qu'à regarder à gauche lorsque je commence à traverser.

Lorsque je visite un pays où la conduite est à gauche, regarder à gauche ne peut me faire tuer.

Les règles sont énoncées très fortement pour une raison.

Ce que vous faites est votre propre problème.

le point d'écrire le test est d'abord, il vous fait penser à

• comment tester le code
• l'interface que le code doit présenter pour pouvoir être testé

si vous faites quelque chose de simple, peu importe celle que vous écrivez en premier (bien qu'il soit bon de cultiver l'habitude du test d'abord), car le test sera simple et l'interface évidente

mais TDD évolue dans les tests d'acceptation, pas seulement les tests unitaires, et l'interface devient alors non triviale.

Tout d'abord, si vous n'écrivez pas d'abord vos tests, vous ne faites pas de développement piloté par les tests (TDD). Les avantages sont nombreux et souvent difficiles à croire jusqu'à ce que vous le pratiquiez plusieurs fois. Voici les avantages que j'ai obtenus avec TDD par rapport au développement traditionnel:

1. Un filet de sécurité de tests - vous permet de faire de grands changements sans craindre de casser quelque chose sans le savoir
2. Conception organique - la conception que je finis est généralement différente de celle que j'aurais faite à partir de zéro et elle a toujours été meilleure
3. Productivité - viser de petits objectifs (réussir ce test) et le faire (tous les tests réussis) fonctionne vraiment bien pour moi et me motive. Ajoutez la paire et ma productivité atteint de nouveaux sommets.

Books: Beck, K. Le développement piloté par les tests, par exemple

Bon exemple: http://jamesshore.com/Blog/Lets-Play/

Lorsque vous écrivez un test, comment savez-vous qu'il détectera une condition d'échec? La réponse est "testez le test". Pour ce faire, vous écrivez le test en premier, vous le voyez échouer et ne le voyez réussir que lorsque l'unité testée a été codée avec succès (cycle rouge / vert / refactorisation mentionné dans l'une des autres réponses).

Écrire le code en premier et ensuite le test laisse ouverte la question de savoir si le test montrerait un échec honnête.

N'oubliez pas que vos tests spécifient les spécifications. Si vous devez réviser vos tests au fur et à mesure que votre code "prend forme", cela suggère que vos spécifications changent. Cela peut ou peut ne pas être une bonne chose. Cela pourrait signifier que votre compréhension du problème n’était pas correcte au départ. D'un autre côté, cela peut vouloir dire que vous testez "comment" l'unité fait son travail plutôt que ce qu'elle est supposée accomplir.