Oui, vous avez bien entendu - c'est vrai! Dans la communauté informatique, l'opinion est fermement ancrée que tous ces tests vous aident d'une manière ou d'une autre, mais est-ce vraiment le cas? Avez-vous essayé de penser de manière critique et d'analyser vous-même cette sagesse conventionnelle? Les hipsters proposent un tas de paradigmes - TDD, BDD, SDA, police de la circulation - juste pour créer l'illusion d'une activité trépidante et justifier d'une manière ou d'une autre leur salaire. Mais pensez à ce qui se passera si vous (ou vos programmeurs) commencez à consacrer tout votre temps exclusivement à l'écriture de code? Il y a une zone séparée pour les tests et des divisions entières. Vous ne forcez pas les programmeurs à écrire des exigences, n'est-ce pas? Alors pourquoi devraient-ils écrire des tests? Tous ceux qui sont d'accord et en désaccord, veuillez aller dans le post, où je vais clairement vous montrer que les tests unitaires (et d'intégration) sont un grand mal!
D'où viennent les tests?
Dans les temps anciens, il n'y avait aucun test du tout. Il n'y avait même pas une telle direction, encore moins des termes tels que les tests de bloc (unité) et d'intégration. Et à propos de toutes sortes d'e2e et, Dieu me pardonne, de pipelines, je me tais généralement. Et tout ça parce qu'en fait, il n'y avait encore rien à tester. Au cours de ces années, les ingénieurs logiciels essayaient seulement de créer les premiers ordinateurs.
Comme nous le savons tous, les premiers ordinateurs étaient gigantesques, pesaient des dizaines de tonnes et coûtaient plus cher que votre Apple MacBook Pro Retina 4k 32Gb RAM 1Tb SSD Touch Bar USB Type-C. Et à cette époque, les développeurs avaient vraiment peur que quelque chose se passe mal pendant le travail. Je pense que vous connaissez l'histoire de l'origine du terme «bug» - si tout à coup non, alors lisez-le , c'est très intéressant. Et comme les programmeurs avaient peur de tout, ils ont proposé des tests unitaires.
Les temps ont changé, les ordinateurs ont également changé. Les tests ont également changé. En plus des tests unitaires, tout un domaine a également émergé, qui est devenu plus tard connu sous le nom d'assurance qualité.
Mais les développeurs ont également changé. De nos jours, il devient ridicule de penser que quelqu'un a peur de lancer un programme, car cela pourrait mettre le feu au serveur. En 2020, les programmeurs n'ont pas peur de lancer leurs programmes. Et s'il n'y a pas de peur, pourquoi tester?
Réalités modernes
Je répète ma question - si votre MacBook (ou Xiaomi) n'explose pas à cause d'un bug dans le code, pourquoi tester alors? Vous venez de lancer et d'apprécier le résultat. Anticipez votre indignation face au coût élevé des erreurs pour le client - laissez des personnes spécialement formées effectuer les tests.
. , . - . . -, Quality Assurance – , ¯\_(ツ)_/¯
, Software Development, Unmistakable Development. .
-, : «, , ». ? ?
. – . . , , , ?
: « » - .
, master, , . pull request , – . , , .
:
, .
, . , , , , . , -, .
.
– . – . ? .
, . , . , . , .
, , . , QA , . , – , .
– . .
Unit-testing, Integration Testing, End 2 End, Pipelines, CI, CD – , ? , , .
. , , e2e , . – .
- CI CD – . devops, . - , - , – .
. , – . – . – bash. … , .
Delivery In Time
: DIT – Delivery In Time. ( ****), . . , , . DIT , – , . , . , : – , – , . , , .
DIT . , ( ), . . , , Quality Assurance . .
:
– ?
– .
– .
– … , 1000 .
. , .
, DIT , , . , . - (, , , ), .
: – , . - , , , . .
, . .
- , (, , ) . , , - . , ? , , .
. , . , – . , , , .
. , , . , ? , , , ? , . , - . – .
. (, 2 ) – . , , . , , . . .
, ? . . , .
. . – , – . - , . , . .
!
, , :)
, . , . , . , , 15%. . , .
? / 80%? - 30? – , ?
, . , , :)
Et, saisissez cette opportunité: si vous avez aimé ce format, alors je vous invite sur mon blog d'un mauvais développeur (ment souvent) public VK , où je poste de temps en temps de tels articles sarcastiques, qui sont souvent peu pratiques à poster ici.