Un nouveau nom pour les tests unitaires [clôturé]


9

Je n'ai jamais aimé les tests unitaires. J'ai toujours pensé que cela augmentait la quantité de travail que je devais faire.
Il s'avère que cela n'est vrai qu'en termes de nombre réel de lignes de code que vous écrivez et en outre, cela est complètement compensé par l'augmentation du nombre de lignes de code utile que vous pouvez écrire en une heure avec des tests et un développement piloté par les tests.

Maintenant, j'adore les tests unitaires car ils me permettent d'écrire du code utile, qui fonctionne souvent la première fois! (touchons du bois)

J'ai constaté que les gens hésitent à faire des tests unitaires ou à démarrer un projet avec un développement piloté par les tests s'ils sont soumis à des délais stricts ou dans un environnement où d'autres ne le font pas, donc ils ne le font pas. Un peu comme un refus culturel d'essayer même.

Je pense que l'une des choses les plus puissantes des tests unitaires est la confiance que cela vous donne pour entreprendre une refactorisation. Cela donne également un nouvel espoir, que je peux donner mon code à quelqu'un d'autre pour refactoriser / améliorer, et si mes tests unitaires fonctionnent toujours, je peux utiliser la nouvelle version de la bibliothèque qu'ils ont modifiée, à peu près, sans crainte.

C'est ce dernier aspect des tests unitaires qui, je pense, a besoin d'un nouveau nom. Le test unitaire ressemble plus à un contrat de ce que ce code devrait faire maintenant et à l'avenir.
Quand j'entends le mot test, je pense aux souris dans des cages, avec plusieurs expériences faites sur elles pour voir l'efficacité d'un composé. Ce n'est pas ce que sont les tests unitaires, nous n'essayons pas un code différent pour voir quelle est l'approche la plus affective, nous définissons les sorties que nous attendons avec quelles entrées. Dans l'exemple des souris, les tests unitaires ressemblent davantage aux définitions du fonctionnement de l'univers, par opposition aux expériences effectuées sur les souris.

Suis-je sur le crack ou quelqu'un d'autre voit-il ce refus de faire des tests et pense-t-il que c'est une raison similaire pour laquelle il ne veut pas le faire?
Quelles raisons donnez-vous / les autres pour ne pas effectuer de test?
Selon vous, quelles sont leurs motivations à ne pas effectuer de tests unitaires?

Et en tant que nouveau nom pour les tests unitaires qui pourraient surmonter certaines des objections, que diriez-vous de jContract? (Un peu centré sur Java je sais :), ou des contrats unitaires?


14
Qu'est-ce qu'il y a dans un nom? ce que nous appelons une rose Par tout autre nom aurait une odeur douce; - Shakespeare, Roméo et Juliette, vers 1600
Steven A. Lowe

8
Je ne sais pas si tu es sur le crack. Je n'ai jamais essayé le crack, ni être toi.
Tim Post

1
Je pense que les idées s'attachent aux mots principalement en raison des idées et des attitudes qui leur sont attachées, pas des mots. Je me souviens avoir découvert que la Spastics Society avait changé de nom pour Scope, car ce nom était associé à des préjugés. Je m'en souviens parce que cela expliquait pourquoi j'avais entendu des enfants s'appeler "scopey" plus tôt dans la journée. Si vous voulez changer d'attitude, concentrez-vous sur l'attitude, pas sur le nom - obséder sur le nom est juste une perte de temps.
Steve314

2
Design by Contract: en.wikipedia.org/wiki/Design_by_contract A une conotation spécifique, et les tests unitaires ne le sont pas. Si je vois quelque chose avec Contract dans le nom, c'est (et les interfaces) que mon cerveau y associe.
Berin Loritsch du

@ Steve314 Scopey. J'aime ça. :) Je pense que dans ce cas, le mot testing est déjà défini, et donc renommer les tests unitaires en un terme non défini serait mieux. Le contrat ne peut pas l'être en raison de l '«interface» mentionnée. Que diriez-vous de «créer de meilleurs programmes plus rapidement» ou CBPF.
Will

Réponses:


5

Suis-je sur le crack ou quelqu'un d'autre voit-il ce refus de faire des tests et pense-t-il que c'est une raison similaire pour laquelle il ne veut pas le faire?

Le mot test dans les tests unitaires fait croire aux gens qu'il s'agit de tests d'intégration ou de tests d'interface utilisateur, car c'est le seul type de test qu'ils aient jamais fait. C'est comme mettre java en javascript.

Quand quelque chose a une mauvaise réputation et affecte la réflexion des gens, cela s'appelle une erreur de cadrage. Les erreurs de cadrage ont tendance à être superficielles - les gens sont intelligents et peuvent voir toutes sortes de mauvais noms, de mauvaises métaphores.

Quelles raisons donnez-vous / les autres pour ne pas effectuer de test?

Dépendances difficiles à simuler / fausses /

Selon vous, quelles sont leurs motivations à ne pas effectuer de tests unitaires?

Les tests unitaires ont un nombre de concepts modeste et un travail non trivial doit être effectué avant de cesser d'écrire de mauvais tests unitaires et de commencer à en écrire de bons. À mesure que les gens expliqueront mieux ce qu'est le test unitaire, l'adoption augmentera. D'après mon expérience, les tests unitaires ont un effet presque magique sur la productivité et la qualité du code. Mais ça n'a pas commencé comme ça. J'ai utilisé à l'origine des frameworks de tests unitaires comme un moyen pratique d'écrire des tests d'intégration.


Grands points. Il est difficile d'essayer d'expliquer pourquoi vous `` testez '' une méthode get simple, expliquant pourquoi il est contractuellement important pour la stabilité de tout le reste de votre code que la méthode get renvoie toujours ce que vous attendez est un argument plus facile à faire
Will

3

Le concept d'un changement de nom a déjà été proposé. C'est ce qu'on appelle le développement axé sur le comportement . Les gars qui sont venus avec cela ont remarqué une grande partie des mêmes arguments, plus l'ajustement contre nature pour tester quelque chose qui n'a pas encore été créé. Au lieu de cela, leur concept est d'écrire une spécification exécutable (ce qui est de toute façon le TDD).

J'ai remarqué le même refoulement. J'ai également remarqué qu'un certain nombre de personnes ne savent tout simplement pas comment écrire des tests unitaires. Ils manquent dans les disciplines des processus scientifiques et utilisent simplement le cadre de test unitaire comme un moyen de tout connecter ensemble et de démarrer le débogueur. Bref, ils n'améliorent pas vraiment l'utilisation de leur temps. Je ne peux pas vous dire combien de tests unitaires j'ai vu qui faisaient plusieurs dizaines de lignes (30+ lignes) et pas une seule affirmation. Quand je vois cela, je sais qu'il est temps de travailler avec le développeur et de leur enseigner ce qu'est une assertion et comment écrire des tests unitaires qui testent réellement.


2
La spécification exécutable est probablement antérieure à TDD / BDD / Agile / XP. Il pourrait être aussi ancien que CMMI. Auparavant, c'était une co-mode avec UML quand les gens pensaient que UML était le langage pour écrire des ES.
rwong

BDD, comme TDD, est une approche de test, pas une sorte de test (fonctionnel v intégration v unité v acceptation). L'auteur demande spécifiquement un «meilleur» nom pour les tests unitaires.
ybakos

0

Les contrats sont appelés «interfaces» dans la plupart des cas ici. Avoir des tests unitaires ne garantit pas les contrats en soi, car vous pouvez également modifier les tests, donc vous ne savez pas vraiment que vous pouvez utiliser la nouvelle version de la bibliothèque simplement parce que la bibliothèque est testée. Vous devez également tester le code qui utilise la bibliothèque. Ce n'est pas différent de tout autre test unitaire, donc je ne vois pas pourquoi cela aurait besoin d'un nouveau nom.

Je pense, comme vous, que la plupart des gens qui hésitent à faire des tests le font parce qu'ils pensent que c'est plus de travail et inutile.


0

Je vais vous dire pourquoi je n'aime pas TDD: ce n'est pas parce que je ne peux pas en voir la valeur, ou reconnaître les avantages d'une suite de tests que je peux exécuter pour vérifier tout mon code après chaque modification.

C'est parce que je n'en ai pas besoin. Je suis un développeur assez old-school, quand j'étais enfant, nous n'avions pas de débogueurs intégrés sophistiqués avec éditer et continuer à écrire du code, et une compilation pouvait prendre assez de temps, donc nous devions obtenir des choses à droite, dès le début. Avec une telle formation, je ne vois pas vraiment qu'écrire une charge de tests unitaires me rendrait plus productif ou mon code plus exempt de bogues.

Je teste mon code, mais comme je l'ai toujours fait, cela concerne la chose entière plutôt que les pièces individuelles. Alors peut-être que j'ai des «tests unitaires», mais ils sont plutôt plus grossiers.

Voilà ma raison. Je ne vois pas la nécessité pour moi de le faire. Le code que je produis est assez bon et si c'est le cas, pourquoi devrais-je changer mes processus pour réparer quelque chose qui n'est pas cassé?


Vous devez alors écrire du code très simple. La quantité d'états accessibles dans la plupart des systèmes modernes signifie que faire des tests de bout en bout prendrait la durée de vie de l'univers - tester deux pièces chacune avec 4 bits d'état prend 16 cas pour chacun, ou 32 cas de test au total; transformé en un système de bout en bout donne 8 bits d'état ou 256 cas de test pour couvrir tous les états. Personnellement, je préfère faire 1/8 du travail.
Pete Kirkham,

1
@PeteKirkham le corollaire de cela est que vous devez écrire un grand nombre de tests unitaires, puis également écrire les tests d'intégration pour vous assurer que l'unité fonctionne toujours les uns avec les autres. Les endroits où je travaillais et qui aimaient beaucoup les tests unitaires ont passé tellement de temps à les écrire (et à les entretenir) qu'ils ont éclipsé la base de code, et la quantité de travail qu'ils ont effectuée était minuscule par rapport à ce que je fais en dehors de cet environnement. Rien n'est magique, je recommande d'essayer de trouver une approche plus pragmatique qui vous offre à la fois une couverture de test des bits importants tout en produisant quelque chose.
gbjbaanb
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.