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

Il ne s'agit pas d'être stupide ou intelligent, mais d'assurer la qualité et la maintenabilité du code. Si vous ne souhaitez pas faire cela, alors n'écrivez pas de tests.

J'écris des tests pour tout car, dans 99 % des cas, une application va changer et les tests garantissent que l'application ne se cassera pas lorsque les changements seront effectués.

Answer 2

Quels tests faites-vous ? Combien de fois retestez-vous lorsque vous apportez un changement ? Le travail des tests réduit-il la quantité de tests que vous effectuez ?

Pour moi, il est plus amusant d'écrire des tests reproductibles que de les faire à la main, encore et encore.

Dans l'ensemble, la chose la plus importante pour moi est de tester suffisamment souvent pour attraper les bogues.

Ce qui m'a surpris, c'est que lorsque j'ai commencé à écrire des tests unitaires explicites, je pense que mon code s'est amélioré. En considérant simplement les tests nécessaires, j'ai réfléchi plus attentivement aux cas extrêmes.

La grande astuce consiste à décider où concentrer l'effort de test. L'interface utilisateur ? Je les teste à la main. Les moteurs de calcul complexes - j'écris beaucoup de cas de test.

Answer 3

Si personne ne retouche le code, il n'est pas nécessaire d'écrire des tests pour celui-ci, puisque l'un des avantages des tests est la maintenabilité (n'est-ce pas ? =P).

Et si tout ce que vous faites dans votre travail est aussi simple, vous n'avez même pas besoin de vous préoccuper de TDD ou des meilleures pratiques. Mais vous devriez peut-être envisager de changer de travail si vous voulez apprendre de meilleures techniques de développement.

Dans ce type de travail, votre patron n'acceptera pas que vous preniez autant de temps pour écrire des tests et coder.

Answer 4

Les tests sont un sens d'assurer la qualité et la maintenabilité du code. Des tests mal écrits n'aident cependant personne et peuvent souvent donner un faux sentiment de sécurité qui rend les bogues plus difficiles à détecter.

EDIT :

Un code de haute qualité et facile à maintenir commence par une bonne conception - un projet doit envisager ce qui peut mal tourner avant l'écriture du code, et écrire en fonction de cela. Je ne dis pas que les tests sont mauvais, je dis simplement que vous ne pouvez pas dire le font tout le temps, parce que c'est ce qui est "bien". et ensuite penser que vous avez tout compris. Comme toute autre "règle", elle n'a de sens que si vous comprenez suffisamment pourquoi vous la faites pour bien la faire.

Answer 5

Comme je l'ai mentionné dans une autre discussion, j'étais un partisan du TDD jusqu'à ce que je l'expérimente sur un projet réel - plus maintenant.

Cependant, je trouve que les tests automatisés sont très utiles, en particulier les tests d'acceptation, d'intégration et de régression. Je ne pense pas que le processus de développement doive être centré sur les tests. De même, je n'ai pas vu beaucoup d'avantages aux tests unitaires - peut-être parce que j'utilise principalement des langages typés statiquement.