Annotation

L'article parle de la forme non conventionnelle mais utile des tests et résume également les résultats de sept années de travail dans le développement de tests.

Pourquoi avez-vous besoin de tests de composants?

Après tout, il y a, disons, des tests unitaires qui testent en détail les abats de composants. Ils vérifient soigneusement que le composant fonctionne conformément à l'intention du développeur. Mais souvent, il s'agit d'une vérification des boutons, et non de la façon dont le costume dans son ensemble se trouve. Et pas toujours le comportement conçu par le programmeur coïncide avec ce que le client voulait.

Et il y a, par exemple, des tests d'acceptation. Et ils éliminent toutes ces lacunes. Mais, malheureusement, ils en introduisent de nouveaux. Ils sont lents, souvent instables et généralement apprivoisés. Cependant, ils indiquent uniquement un problème, mais ne le localisent pas.

De toute évidence, le besoin se fait sentir de tests intermédiaires, qui seront le juste milieu entre les tests unitaires et les tests d'acceptation. Ce terrain d'entente peut être des tests de composants.

Que sont les tests de composants?

Ce sont des tests pour l'API du composant public. En conséquence, ils sont écrits dans la même langue que le composant. Objectif du test:

• vérifier la conformité des composants avec vos contrats
• vérifier la conformité
  Ce dernier est particulièrement important car les tests unitaires sont généralement écrits en fonction des attentes du développeur, mais ici, vous devez vérifier les attentes des clients.

De toute évidence, les tests de composants ont un sens lorsque vous avez des composants dédiés avec une interface étendue. Par exemple, une bibliothèque dynamique ou un objet COM. Ensuite, les tests de composants donneront l'effet maximum.

Avantages des k-tests:

• Donnez de la stabilité au développement. De toute évidence, une vérification complète des interfaces publiques vous permet de conserver le composant sous une forme plus ou moins efficace.
• Localisez avec précision les problèmes. Même si le test de composant lui-même est assez général, il peut toujours être débogué en profondeur, pour arriver rapidement au code de bataille. Dans ce cas, l'environnement de test sera minimal et configuré automatiquement.
• Accélérez le développement avec un nombre critique de développeurs. Les programmeurs sont connus pour être comme des chevaux. Si un cheval tire un chariot d'une capacité de 1 litre. s., puis huit chevaux sont tirés avec une capacité d'environ 4 litres seulement. s Et l'ajout d'un autre développeur à l'équipe (en particulier à la fin du projet) non seulement n'accélère pas, mais le ralentit également. Bien que l'ajout d'un développeur de test de composants soit toujours un plus, car il agit relativement indépendamment de l'équipe: il effectue des tests (essentiellement externes), accélère la construction de la construction, optimise les fichiers d'assemblage, etc.
• Clarifier (puis vérifier) ​​les exigences des clients. Le développeur des tests de composants n'étant pas lié à l'implémentation, il est moins affecté par l'effet "Je sais comment le faire moi-même". Dans le cas d'une exigence ambiguë, le développeur ordinaire est enclin à faire aussi pratique (plus intéressant, plus rapide, plus facile). Alors que le développeur ct dans ce cas est enclin à spécifier ce qui est exactement attendu par le client.
• Relativement stable et relativement rapide (par rapport aux tests manuels et aux tests automatisés via l'interface utilisateur).

Inconvénients des K-tests:

• Temps de développement et de support. De toute évidence, la version alpha du produit, si une partie du temps est consacrée à la rédaction des tests de composants, apparaîtra plus tard. Y aura-t-il un gain en général? Y aura-t-il une sortie plus tôt? C'est une bonne question. Mon avis: lors du développement avec des tests de composants, la version sortira à peu près au même moment. Mais - avec moins de rumeurs et plus prévisible en termes de temps. Le temps de développement augmentera naturellement, le temps de correction de bogues et de stabilisation sera réduit. Étant donné que la deuxième partie est beaucoup moins prévisible, sa réduction aura un effet bénéfique sur la quantité de traitement et les tracas. Cependant, ce n'est que mon expérience, et la réalité peut être différente. Il est possible que le temps alloué aux tests de composants soit inutilement consacré à la duplication de tests unitaires existants.
• Moins d'interchangeabilité. La séparation des rôles augmente l'efficacité, mais réduit l'interchangeabilité. Les développeurs souhaitent rarement approfondir les tests de composants, qui peuvent avoir (ou simuler) un environnement assez complexe. Les développeurs de tests de composants sont loin de connaître si bien le code de bataille qu'il peut être facilement édité.
• Duplication ennuyeuse. Avec de bons tests unitaires, les tests de composants s'avèrent souvent redondants. C'est à la fois ennuyeux et remet en question leur besoin. La coordination des plans unitaires et des tests des composants est utile, mais la duplication n'est généralement pas complètement éliminée.
• La nécessité de suivre le bon workflow. Dès réception des exigences, la tâche doit être confiée simultanément au développeur et au développeur des tests. Ensuite, ils terminent leur travail à peu près au même moment. Le composant est soumis à des tests, les erreurs sont rapidement détectées et corrigées et un produit plus ou moins fini est utilisé pour quitter. Dans ce cas, les avantages des tests de composants sont maximisés. Mais il arrive souvent que les délais soient profanes depuis longtemps, tous sont abandonnés pour écrire uniquement du code, et le composant est envoyé à des tests manuels sans tests. Et seulement alors, ils invitent le développeur des tests - ils disent que ce n'est pas bien que le code sans les tests ait été publié, il serait nécessaire de les ajouter. Dans ce cas, la plupart des bogues sont détectés par des testeurs manuels, les développeurs apportent des corrections à l'aveugle (ou testent les modifications elles-mêmes à la main), et les tests post-factum ne détectent qu'un petit nombre d'erreurs (ce qui affecte négativement la morale de leur auteur). Une telle utilisation des tests de composants est au mieux inutile et il est difficile de s'en assurer.
• Il y a peu de personnes appropriées. Le développeur de tests de composants doit, d'une part, être capable d'écrire du code dans le langage du composant (et ce, par exemple, C ++). De plus, si l'environnement de lancement du composant est étendu, le code peut être assez compliqué. Et d'autre part, être capable de tester méticuleusement le travail de quelqu'un d'autre. Il n'y a pas beaucoup de ces personnes, et elles vont généralement immédiatement aux développeurs. Mais il y a encore de telles personnes, et la prochaine partie à leur sujet.

Résumé 1

Les tests de composants sont bons, mais seulement si vous disposez de toutes les conditions: une large API publique, le bon flux de travail et les bonnes personnes dans l'équipe.

Comment est-ce d'être un SDET?

De toute évidence, SDET - Software Development Engineer in Test est un candidat idéal pour écrire des tests de composants. Il sait écrire du code et sait penser dans les tests. Il fournit également un deuxième avis, ce qui améliore également la qualité des tests et du code. Tout cela semble intéressant et tentant - peut-être que vous voulez déjà en être un. Ici, je vais brièvement vous expliquer en quoi le travail de SDET diffère du travail d'un pur développeur.

Avantages de travailler avec SDET:

• Nouveau code. Presque toujours, SDET écrit des tests à partir de zéro. Et assez souvent, un environnement est écrit à partir de zéro. Il est très agréable et laisse une grande place à la créativité.
• Faible dépendance à l'égard du code hérité. Peu importe la gravité du code de bataille, les tests peuvent être effectués avec compétence et beauté. Bien sûr, un code mal conçu génère des tests laids, mais ils peuvent toujours être améliorés d'un ordre de grandeur par rapport au code lui-même.
• Refactoring plus fréquent. Les changements dans les tests sont beaucoup moins dangereux, par conséquent, ils sont convenus plus souvent. C'est une bonne occasion de travailler sur les bugs et de pratiquer l'écriture de code propre par le refactoring.
• Le développement de la pensée critique. Les autotests sont une recherche intéressante pour savoir comment casser le code de quelqu'un d'autre. De plus, la recherche n'est pas stupide, ne pas s'asseoir et piquer, mais avec l'aide de la logique, de la combinatoire et de la capacité de voir les vulnérabilités. De plus, une fois créé, un chèque continuera de fonctionner pour vous en permanence.
• Développer la capacité de tester le code. Dans l'entraînement au combat au corps à corps, ils donnent souvent des mots d'introduction: "maintenant nous ne travaillons qu'avec nos pieds; maintenant nous ne travaillons qu'avec nos têtes." L'utilisation d'un seul mécanisme (dans notre cas, les autotests) vous permet de l'affiner pour la maîtriser.
• Moins de rumeurs. Les SDET sont beaucoup moins tirés pour le week-end. Ils n'ont pas besoin de se mettre au travail de toute urgence pour corriger les bogues critiques. Eh bien, ils ont beaucoup moins de chances de commettre une grave erreur.

Inconvénients de travailler avec SDET:

• Faible complexité de codage. Le code de test est généralement encore plus simple que le code de bataille. Conditions préalables, appel du code de bataille, postconditions - et ainsi de suite pour chaque test. Le code pour créer l'environnement est plus compliqué, mais n'atteint toujours pas le combat. Sélection d'algorithmes optimaux, conception de structures de données complexes, création de hiérarchies de classes - généralement, tout cela passe par le développeur de test.
• L'expérience gagne plus lentement . La variété et la complexité des situations dans lesquelles tombe le développeur de test est bien moindre. Échec de la chaîne de montage, tests rouges, parfois vidages - c'est l'ensemble principal avec lequel vous devez habituellement travailler. Le développeur a beaucoup plus de problèmes: à partir des variations de liaison et d'assemblage, en continuant avec des problèmes chez un client particulier et en créant des vidages, en terminant par la recherche de bogues dans le compilateur et les bibliothèques tierces. Et pas seulement ...
• Une différence majeure dans le style de test avec les développeurs. Habituellement, les SDET préfèrent les tests expressifs compacts qui vous permettent de créer un environnement complexe en quelques lignes seulement, et les vérifications atomiques dans le style sont égales / non égales (c'est-à-dire que l'exigence est satisfaite ou non). Parfois, il s'agit de sa DSL. Simplement, les développeurs préfèrent les tests avec un réglage fin de l'environnement et de nombreux tests de divers aspects du comportement du programme, ce qui conduit à des tests assez multi-lignes. Parfois, il s'agit de copier-coller (que même les meilleurs développeurs ne considèrent pas le péché dans ce cas). Ici, vous pouvez discuter pendant longtemps de la meilleure façon ou même écrire un article séparé, mais le fait est que lorsqu'un développeur essaie de modifier les tests SDET (ou vice versa), cela conduit souvent à des discussions longues et inefficaces.
• Ci-dessous est le "grade". Peut-être en raison d'un code plus simple et de moins de responsabilités, mais finalement pas important. C'est généralement comme ça.
• Plus difficile de passer à un nouveau poste. SDET pourrait bien poser la question sur le front: vous écrivez des tests depuis si longtemps, c'est-à-dire que vous venez d'appeler des fonctions et de comparer les résultats - pouvez-vous écrire du vrai code? Connaissez-vous tous les pièges de la langue? Avez-vous résolu des problèmes complexes? Avez-vous dû démonter des bogues ou des décharges ornés? Y a-t-il une expérience avec le multithreading? Avez-vous, après tout, des ambitions?

Résumé 2

En tant que personne qui a travaillé en tant que développeur pendant de nombreuses années, puis est allé aux SDET pendant plusieurs années, puis est retourné au développement, je peux dire ce qui suit.

Je recommande fortement de passer un SDET pendant au moins un an ou deux. C'est une expérience très enrichissante pour tout développeur. Mais y rester, à mon avis, ne vaut pas la peine.