Je n'écris pas de tests. Suis-je stupide ?

Question

J'ai lu un peu sur les tests unitaires et le TDD, et je n'ai jamais sérieusement envisagé d'écrire des tests de façon aussi précise. Il est vrai que je ne travaille pas sur des projets qui sont ridiculement énormes. Si je ne construis que de petites applications, suis-je stupide de ne pas écrire de tests ?

Modifier : Pour clarifier, quand je dis "petites applications", je veux dire des applications qui ne vont pas contrôler la vie d'une personne et/ou ses biens. Je construis généralement des choses qui sont censées faciliter la vie des gens et les rendre plus efficaces.

Answer 1

Tout le code ne peut pas être testé de manière unitaire et cela ne convient pas à toutes les situations. Choisissez donc quelque chose qui ne soit pas axé sur l'interface pour commencer, comme quelque chose de financier ou de basé sur des calculs. Essayez-le et vous finirez peut-être par l'aimer.

Answer 2

Le TDD et les tests unitaires dans leur ensemble ne vous seront utiles que si vous devez "maintenir" votre code. Si vous devez ajouter une fonctionnalité par exemple, ou si vous devez avoir un nombre raisonnablement bas de défauts, et donc avoir besoin de les corriger. Si vous ne maintiendrez jamais le code, alors les tests unitaires ne feront que nuire à la productivité. Cela peut être le cas pour les petits scripts et applications, où les tests manuels (d'acceptation) sont tout ce qui est nécessaire.

Avant d'envisager d'accepter une police, demandez-vous toujours quelle valeur ajoutée elle apporte à l'entreprise. Ceci étant dit, je trouve que c'est le cas extrêmement rare dans le domaine de la programmation où les tests unitaires sont un obstacle plutôt qu'un avantage.

Answer 3

Je ne vais pas répéter tous les avantages de la TDD énumérés ici et dans de nombreuses autres ressources. Cependant, je peux dire pour moi-même qu'une fois que vous êtes à l'aise avec le cadre de test de votre langue le temps nécessaire pour écrire un test est à peu près le même que pour tester manuellement le code . Ainsi, je préfère faire un test qui restera là et vérifiera toujours l'exactitude du code au lieu de le tester manuellement à chaque fois que quelque chose change même s'il ne change "jamais".

Parfois, je vois des gens qui créent une méthode principale et testent manuellement leur code en imprimant les résultats et en les regardant. Mec, fais juste un test - c'est la même quantité de code :)

En outre, la méthodologie TDD permet d'écrire des logiciels plus modulaires, testables et faciles à utiliser. bénéficie non seulement de la testabilité mais aussi de la configurabilité et de la flexibilité. de votre demande.

Answer 4

Plus le projet est important, plus il est important d'écrire des tests. Si vous êtes seul à travailler sur un petit projet, c'est généralement une bonne idée d'écrire des tests. Si vous et une équipe travaillez sur un projet de taille moyenne à grande, il est nécessaire d'écrire des tests complets et significatifs si vous voulez fournir un code de qualité et maintenable.

Answer 5

Bien que l'un des principaux avantages du TDD soit de garantir l'intégrité de votre code en vérifiant qu'il fonctionne, ce n'est pas le seul. L'autre avantage majeur du TDD, s'il est fait correctement, est que vous isolez une partie de la fonctionnalité et développez contre elle. Lorsque vous écrivez vos tests avant votre code, vous vous obligez à réfléchir à ce que votre méthode doit faire exactement en fonction du résultat attendu.

Lorsque vous suivez cette approche depuis le début, vous écrivez vos tests pour votre fondation et, à mesure que vous progressez dans l'application, vous voyez des points sur lesquels vous pouvez réfracter et affiner le code. Lorsque vous appliquez ces changements, le test lui-même joue son rôle vital et vous informe si vous avez affecté autre chose dans l'application.

L'utilisation de tests pour concevoir des logiciels exige un changement majeur dans votre façon de penser. Même aujourd'hui, lorsque j'échoue à faire du développement basé sur les tests, j'ai du mal à renvoyer et à écrire des tests. Cela devient une tâche fastidieuse que je préfère ne pas faire. Cependant, lorsque je les écris en premier, cela devient un processus critique de conception. J'ai constaté que c'est beaucoup plus difficile à faire lorsque j'entre dans un projet qui est en cours.

Edit : Il n'y a rien de tel que la satisfaction que vous ressentez lorsque vous écrivez une méthode qui ne cesse d'envoyer un signal rouge et que vous avez un moment "ah-ha" et que vous voyez cette bulle devenir verte, ou le sentiment de soulagement que vous ressentez lorsque vous apportez un petit changement qui, selon vous, n'aura pas d'incidence sur le reste de votre application et que les feux rouges s'éteignent.