En tant que développeur professionnel, est-il acceptable de ne pas écrire de tests unitaires? [fermé]

Vous vous demandez simplement les avantages et les inconvénients des tests unitaires TDD / automatisés et recherchez l'opinion de la communauté sur la possibilité pour les développeurs professionnels d'écrire des applications sans prendre en charge les tests unitaires?

Pour tester quoi?

Si vous parlez d'une couverture de code à 100%, c'est extrêmement rare, inutile et souvent impossible. De la même manière, tester le code lié à CRUD est une perte de temps, et il serait très peu professionnel de passer des heures à écrire du code dont vous n'avez pas besoin au lieu de faire quelque chose d'utile.

Maintenant, en tant que développeur, vous devez savoir comment écrire des tests unitaires et où en avez-vous besoin.

Théorie

Il y a une idée fausse commune selon laquelle les tests unitaires sont destinés à tester des "unités" .
Les tests unitaires, comme tous les autres tests, testent la fonctionnalité . Rien d'autre ne peut être testé.

Cependant, la fonctionnalité d'un système complexe ne peut souvent pas être testée efficacement.
Disons, un utilisateur appuie sur un bouton "Supprimer", et rien ne se passe. Pourquoi? Une erreur peut se trouver dans une base de données, une connexion peut être rompue, une logique de base peut mal fonctionner ou même une opération peut réussir mais l'interface n'a pas été mise à jour correctement. Chaque couche peut contenir de nombreuses fonctions qui s'appellent les unes les autres, et il n'est pas toujours clair où se trouve l'erreur.
Les tests unitaires sont basés sur un paradigme de séparation des composants et de les tester individuellement.

Encore une fois, cela ne garantit pas que tout le système fonctionnera, mais cela simplifie les tests.

TDD n'est pas une exigence en soi. Il simplifie le codage en forçant un développeur à répondre en premier, "que vais-je réellement coder?".

Frais

Beaucoup pensent qu'en n'écrivant pas de tests, ils gagnent du temps. Faux. En pensant stratégiquement, le coût d'une erreur augmente de façon exponentielle avec le temps depuis l'apparition jusqu'à la détection.

Supposons que vous faites une erreur dans votre code et que vous le détectiez et le corrigiez le même jour. Le coût est de X $ .
Supposons que l'erreur reste non détectée et passe à la génération interne hebdomadaire. Heureusement, le QA l'a détecté, a soulevé un bug dans bug tracker, le problème a fait l'objet d'une discussion de 5 minutes sur une réunion de 5 personnes, etc. Enfin, vous le corrigez. Le coût est la somme de la main-d'œuvre dépensée par tout le monde, et il peut être de 3 $ X dans ce cas.
Et si l'erreur passait aux tests bêta et impliquait plus de personnes? Le mot Let, 10 $ * X .
S'il reste longtemps non détecté, est allé à 1000 clients (espérons-le, pas à un million!), 10 d'entre eux l'ont détecté, ils ont discuté avec votre personnel de support, certains peuvent appeler votre patron, vos coéquipiers tentent de le reproduire , etc, etc. Enfin, le bogue vous revient et vous le corrigez. Combien, au total? Eh bien plus de 50 $ * X .

Comme vous le voyez, un bug vous reviendra tôt ou tard (ou votre collègue). La seule différence est quand cela se produit et combien cela coûterait.
Les tests unitaires raccourcissent le cycle de vie des bogues et réduisent donc les coûts.

Avantages

• Les tests unitaires permettent au développeur de mieux coder . Aussi simple que cela.
• Ils permettent de gagner du temps;
• Ils diminuent les coûts;
• Les tests unitaires cohabitent avec le code qu'ils testent. Sur toute demande de changement (qui arrive tout le temps), les tests s'adapteront.

Les inconvénients

Je peux voir une seule excuse pour ne pas écrire de tests. Si vous écrivez un prototype, par exemple quelque chose qui n'ira jamais aux autres. Ou peut-être que vous écrivez quelque chose pour un usage unique.

Bien sûr, il est acceptable de ne pas écrire de tests unitaires pour de petits utilitaires d'assistance internes, ou des outils de test, ou des scénarios où l'entreprise a vraiment vraiment besoin de choses autres que la qualité et vous en tant que développeur professionnel constatez que vous pouvez faire fonctionner le logiciel et travailler aussi rapidement sans pour autant.

D'après mon expérience, 95% des erreurs qui peuvent être détectées par les tests unitaires proviennent d'appels à la couche de données, en particulier après les modifications de conception de la base de données. Si vous utilisez une base de données, testez simplement chaque méthode que vous utilisez pour y accéder. Les tests n'ont même pas besoin d'être élaborés, juste des contrôles de santé mentale.

En réponse à votre question - si vous accédez à une base de données et que vous êtes un développeur professionnel, vous devez utiliser des tests unitaires. Sinon, cela dépend.

Cela dépend vraiment de la façon dont l'application sera utilisée. S'agit-il d'une application essentielle à la mission? Ou s'agit-il d'une simple application de vérification utilisée uniquement en interne par les développeurs? Lorsque vous travaillez sur les applications principales de votre entreprise, il doit y avoir autant de tests unitaires que nécessaire pour garantir que les décisions commerciales sont couvertes. Selon votre entreprise, ce sont les applications que les clients voient et les bogues peuvent coûter cher. Une fois bien effectués, les tests unitaires peuvent être d'une grande aide pour garantir que vos applications fonctionneront une fois déployées. Mais ce n'est pas un remède à tous et des tests humains doivent encore être effectués. Les applications internes (ou auxiliaires) simples n'ont pas besoin de tests unitaires, mais doivent toujours être bien écrites.

TDD ne consiste pas seulement à écrire des tests en premier. Il s'agit de s'assurer que votre code est facilement testable. Et le plus souvent, le code facilement testable est également plus facile à lire / déboguer / maintenir. Le plus souvent, le code facilement testable suit également des modèles et des principes OO tels que SOLID. Je dirais qu'en tant que développeur professionnel, votre code devrait toujours être écrit de cette façon.

Vous ne voulez certainement pas "pas de test". Si vous écrivez des tests unitaires, vous avez au moins une certaine assurance que votre code correspond à vos tests (bien que vous deviez vous assurer que vos tests correspondent à vos spécifications).

Cependant, vous n'avez pas terminé si vous ne disposez que de tests unitaires. Vous devez probablement encore effectuer des tests d'intégration et des tests de bout en bout (et au fil du temps accumuler des cas de test pour détecter les régressions de bogues).

Je vais sortir sur un membre ici et dire que c'est principalement subjectif et dépend de vos objectifs. tl; dnr: C'est bien à faire, mais être dogmatique à ce sujet va juste conduire à plus de problèmes.

Les tests TDD / Unit vont améliorer la stabilité de votre code. Ils facilitent les modifications sans connaître très bien la base de code, ils vous permettent de refactoriser plus rapidement, ils vous permettent d'être sûr que vous ne faites pas quelque chose de stupide. Les tests unitaires peuvent également être une perte de temps. Temps qui pourrait être consacré à l'écriture de code. Cela peut également vous laisser croire que votre code fonctionne quand il ne fonctionne pas si vous les suivez aveuglément.

Si vous travaillez pour une entreprise qui prend en charge les meilleures pratiques et vous donne le temps de les mettre en œuvre et que vous voulez une application qui durera, alors il est vraiment préférable que tout le monde utilise et pratique des tests unitaires et des revues de code. Avoir une équipe QA peut être un substitut acceptable si les développeurs n'en abusent pas. Si vous écrivez un prototype (même de production), il peut être plus rapide de faire des tests de fumée.

Si vous travaillez sur quelque chose où un gâchis ne va pas être la fin du monde, moins de couverture est probablement bien. Transactions financières? Beaucoup. Si vous avez une équipe de développeurs solides qui connaissent la base de code, fonctionnent bien ensemble et qu'il n'y a pas de chiffre d'affaires, alors vous avez probablement besoin de moins de couverture. Etc.

Donc, ça va probablement être une fonction de

• Taille / chiffre d'affaires de l'équipe
• Durée de conservation souhaitée de l'application
• L'application et la gravité des défaillances
• Temps accordé pour mettre en œuvre les meilleures pratiques relatives au calendrier de développement
• Aptitude d'équipe (cela ne signifie pas être un bon programmeur signifie que vous ne devriez pas écrire des tests unitaires, mais une équipe sans développeurs juniors pourrait être capable de voler par le siège du pantalon avec plus de succès)

Il existe de nombreuses situations où ne pas écrire de tests unitaires serait acceptable. TDD est en place en ce moment, mais ce n'est pas une solution miracle.

Il est professionnel d' écrire des tests unitaires maintenables qui vous feront gagner du temps et des larmes!

Il y a un misconception that Unit test finds bugs. Eh bien, ce n'est tout simplement PAS vrai pour tous les cas. Les tests unitaires ne consistent pas à trouver des bogues ou à détecter des régressions. Il est , par définition, examine each unit of your code separately. Mais lorsque votre application s'exécute pour de vrai, toutes ces unités doivent fonctionner ensemble, et l'ensemble est plus complexe et subtil que la somme de ses parties testées indépendamment.

Ainsi, l'objectif des tests unitaires (dans le cadre du processus TDD) consiste à concevoir des composants logiciels de manière robuste.

Edit: Il y a une exception où les tests unitaires détectent réellement les bogues. C'est lorsque vous refactorisez ou restructurez le code d'une unité mais sans vouloir changer son comportement. Dans ce cas, les tests unitaires peuvent souvent vous dire si le comportement de l'unité a changé.

En tant que développeur professionnel, est-il acceptable de ne pas écrire de tests unitaires?

Non.

Sans aucun doute - Cela devrait être l'une des premières leçons qu'un plus frais apprend. Vous devez développer des tests unitaires pour prouver que votre code fonctionne avant de dire à QA que votre code est prêt à être testé. Ne pas le faire gonflerait les coûts du projet et abaisserait le moral de l'équipe.

Quelle doit être la profondeur de ces tests unitaires?

Voici le test décisif: Si QA découvre un bogue dans votre code, serez-vous à l'aise d'utiliser vos tests unitaires pour prouver votre diligence raisonnable à votre patron?

Si votre réponse est «Non», alors vous devriez créer un meilleur test unitaire (ou tests).
Si votre réponse est «oui», votre code est prêt pour la vérification.

En tant que développeur professionnel, est-il acceptable de ne pas écrire de tests unitaires automatisés ?

Oui.

Surtout si le temps et les efforts consacrés à la rédaction de tests unitaires automatisés l'emportaient sur les avantages obtenus par le test. Cela inclut, mais sans s'y limiter, le code d'interface utilisateur qui peut être difficile à moquer.

Souligné: je ne dis pas qu'il est impossible d'écrire des tests unitaires automatisés pour le code de l'interface utilisateur. Je dis simplement que, d'après mon expérience, il est parfois difficile d'écrire des tests unitaires automatisés pour du code d'interface utilisateur.