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

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?

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.

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.

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.

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é?