Dans mon travail, j'utilise constamment des tests unitaires. Et vous? D'après mon expérience, la plupart des programmeurs sont très rares. Lors des entretiens avec les candidats de mon équipe, je pose toujours la question: "Avez-vous une expérience de test?" Et le plus souvent j'entends en réponse: "Non". Et si vous demandez pourquoi, alors la réponse la plus courante sera: "Le client ne m'a pas laissé faire cela."

Cette approche me surprend. Voulez-vous dire au constructeur quelle marque de béton choisir pour construire une maison? Ou la mécanique automobile - quelle partie du moteur à réparer, et laquelle non, si le moteur a clignoté dans la voiture? Il est peu probable, car il s'agit de problèmes techniques graves, dont la solution doit être confiée à un professionnel. Un professionnel possède les compétences et les outils nécessaires qui lui permettent de résoudre un problème plus rapidement et à moindre coût.

Pourquoi compter l'argent

Le Code civil a le concept de «sauver un entrepreneur par l'expérience et la connaissance». Cela signifie que le travail est effectué par un professionnel qui sait comment optimiser le processus, comment faire mieux, mais en même temps moins cher. Et les développeurs en tant que professionnels devraient donner au client les meilleures solutions pour le moins d'argent.

Mais en réalité, les programmeurs se concentrent sur autre chose. Beaucoup d'entre eux sont convaincus que le développement de logiciels est un processus purement technique, qui a, bien sûr, sa valeur, mais le travail du programmeur est d'écrire, pas de compter l'argent. Cependant, à mon avis, le développement est avant tout un projet économique, derrière lequel il y a de l'argent et des calculs, et ce n'est qu'ensuite une tâche technique.

La logique ici est simple: les affaires - aux clients mêmes qui nous commandent le développement de logiciels pour leurs entreprises - n'ont en fait pas du tout besoin de logiciels. Les entreprises ont besoin d'argent, les avantages de ce logiciel.

Cela signifie que les programmeurs ne peuvent pas se passer de comprendre l'économie du développement, de connaître le coût des solutions techniques et lesquelles d'entre elles sont optimales en termes non seulement de technologie, mais aussi de financement.

Le développement de logiciels n'est généralement pas la partie la moins chère de l'entreprise, mais des logiciels de mauvaise qualité peuvent entraîner de grandes pertes. Même les temps d'arrêt entraînent des pertes de profits et les problèmes logiciels peuvent entraîner des millions de pertes. Par conséquent, le développeur en tant que professionnel doit avoir confiance en la qualité de son produit et la garantir à son client. Mais la qualité du produit est l'indicateur le plus important. Et le client doit savoir que cette qualité peut être mesurée et avoir confiance en elle. Et quelle est exactement la tâche du programmeur.

Comme beaucoup de mes collègues, je pense que les programmeurs ne devraient pas discuter de solutions d'ingénierie avec le client. Il suffit en général de savoir ce qui est important pour le client, quelles fonctionnalités et à quelles fins il a besoin. La décision de choisir incombe au programmeur. Et dans le cadre de cette responsabilité, il doit utiliser les meilleures pratiques d'ingénierie pour un projet donné avec des coûts économiquement justifiés. Par conséquent, les professionnels qui savent comment rendre le processus de développement moins cher gagnent.

Quel test est le plus rentable

Une pratique qui vous permet de contrôler la qualité du produit est le test. Mais quel test est le plus rentable? Pour répondre à cette question, il suffit de comparer plusieurs paramètres. Tous les tests peuvent être conditionnellement divisés non seulement par type de technologie, mais aussi par vitesse, et surtout - par coût.

Test unitaire - test des unités de production. Par unités, j'entends les unités de programme, selon la langue représentée par les classes, les fonctions, moins souvent les fichiers. En utilisant l'approche TDD, les tests sont initialement intégrés au processus de développement de produits. Un projet peut utiliser des milliers de ces tests pour tester des morceaux de code individuels. Ils ont un excellent indicateur de vitesse - l'ensemble des tests peut être effectué en quelques secondes. Ce sont les tests les moins chers.

Tests d'intégration - testez 2x-3x ou plusieurs unités ensemble. Il peut y avoir des centaines ou des milliers de tests de ce type sur un projet, selon le programmeur. Vitesse - secondes ou minutes pour toute la suite de tests. Le coût est plus élevé que les tests unitaires.

Les tests d'acceptation simulent les actions de l'utilisateur avec un programme. Ils nécessitent la préparation d'un environnement opérationnel, ils sont donc complexes et coûteux. Quantité par projet - généralement un test est effectué pour une histoire d'entreprise. La vitesse de travail est généralement de quelques dizaines de minutes à plusieurs heures pour l'ensemble des tests.

Le test le plus cher et le plus difficile est le manuel . Vous devez embaucher une personne, la former, créer et lui donner une carte de l'histoire de l'entreprise afin qu'il teste le nouveau logiciel dessus. Ces tests prennent plusieurs jours pour l'ensemble des tests.

Tout type de test nécessite une préparation, ainsi qu'un certain investissement d'argent. Et pour réaliser des économies (et donc des bénéfices), il faut d'abord tenir compte de la rapidité des tests et de la complexité de leur lancement. Si le projet ne comporte pas de tests automatiques, il n'y a qu'une seule issue: les tests manuels, les plus chers et les plus lents.

Cependant, l'approche moderne du développement logiciel est un cycle continu: en une semaine, de nouvelles fonctionnalités ou une nouvelle version sont créées et vérifiées automatiquement ou manuellement. Autrement dit, le produit change fréquemment et toutes ces modifications doivent être contrôlées afin que le programmeur soit sûr que les nouvelles et anciennes fonctionnalités fonctionnent bien. Par conséquent, les tests manuels perdent immédiatement sur tous les indicateurs.

Quant aux différents types de tests automatiques, il y a trois aspects plus importants à considérer.

Tout d'abord, c'est la fiabilité - la facilité avec laquelle il est possible de casser le test (c'est le meilleur indicateur pour les tests unitaires).

Ensuite, l' environnement nécessaire pour exécuter les tests. Les tests unitaires sont très simples, ils créent eux-mêmes un environnement autour de l'unité testée. Les tests d'intégration nécessitent un service qui doit être installé, en cours d'exécution, etc. Les tests d'acceptation nécessitent une préparation, car l'application doit fonctionner dans son environnement.

Et enfin - la couverture (couverture de test). Les tests unitaires ont une bonne couverture et sont utilisés tout au long du projet. Les tests d'intégration sont généralement utilisés sur certaines parties du projet, c'est-à-dire qu'ils ne couvrent pas complètement le programme. La couverture des tests d'acceptation est pire - cela est dû à la complexité de leur rédaction et de leur exécution, le plus souvent ils couvrent les principaux cas commerciaux, cela représente 20 à 40% du volume total du projet.

Conclusion

Il s'avère donc que les tests unitaires sont en tête dans tous les indicateurs de cette brève analyse comparative. Dans ma pratique, le plus souvent je les utilise, ça donne une qualité suffisante. Si les exigences de qualité augmentent, nous passons à l'acceptation. L'utilisation de tests d'intégration dépend du client, qui peut vouloir tester certaines parties du projet.

Ma pile technologique actuelle est angulaire et .net. Et si les tests côté serveur ne soulèvent pas de grandes questions, alors tester l'application client n'est toujours pas évident pour tout le monde. Sur mes projets clients, le nombre de tests unitaires varie de quelques centaines à plusieurs milliers. Dans le prochain article, je vais essayer de partager les techniques clés pour tester les applications angulaires.