J'ai entendu dire que les tests d'unités d'écriture (codage) pour votre application double efficacement le temps de développement requis pour les projets. Est-ce vrai, en particulier pour les débutants?
Aussi quelques questions de suivi (points de brownie): Si vous faites un projet client que vous remettez lorsque vous avez terminé, cela vaut-il la peine et efforts pour effectuer des tests unitaires?
11 Réponses :
Je dirais que le double du temps est une estimation juste et oui, les tests unitaires sont Cependant, je devrais affirmer que le temps passé dans les tests unitaires est nettement inférieur au débogage et corrigez des erreurs plus tard, cela résultait d'un manque de test de l'unité.
Sauf: lorsque les tests sont écrits mais non entretenus.
La raison pour laquelle il en vaut la peine, c'est qu'il diminue le débogage du temps passé. Avec une couverture décente des couches inférieures de la logique, de nombreuses suppositions et boules impairs sont hors de la voie lors du débogage de l'application. Raison de mentionner les couches inférieures, c'est que le test d'unités d'écriture parfois pour des trucs de niveau supérieur nécessite beaucoup de préparation, d'injection de trucs non disponibles, etc., couvrez donc les choses plus faciles.
Sans tests d'unité, pas de refactoring. Sans refactoring, pas de code maintenu (facilement). Pour cela, des tests unitaires sont essentiels.
@Pascal thivent - Exactement, ce n'est même pas un choix imo. Sans tests unitaires, même de petites modifications apportées au code pourraient introduire des bugs cachés, sans parler de grands refacteurs.
@Mitchwhate - Cela ne vaut pas l'effort si votre programme est destiné à une utilisation interne ou juste pour vous, ou même si vous avez moins de client que vous ne pouvez compter sur une main. Je trouve aussi qu'il faut un considérable long temps pour écrire approprié tests d'unité qui attaquent tous les scénarios possibles. parfois même x4 fois plus.
@VSync: Je suis d'accord partiellement avec votre commentaire: les tests d'écriture peuvent être laborieux. Le problème est que de l'expérience que nous savons tous que ce logiciel écrit "pour un usage interne" passe souvent à la production. Plutôt que d'essayer d'obtenir une couverture à 100% avec des tests unitaires, ajoutez des tests d'intégration au test global.
@Mitchwheat - Si vous êtes payé au code, je suppose que vous êtes payé pour écrire des tests. Je suis un homme libre, personne ne me paie plus pour s'asseoir et dépenser des tests de l'écriture de x3 à moins que je ne discute avec le client, il est indispensable. Plusieurs fois dans la vie, vous mettez des considérations d'argent au-dessus des dépenses («gaspillage») du temps à faire une chose laborieuse qui ne vous bénéficiera probablement pas personnellement en termes financiers.
@VSync: Vous manquez totalement le point. Lorsque vous écrivez du code, cela aura des bugs! Peu importe à quel point vous êtes bon ou expérimenté. Les tests aident à fournir une couche de confiance que le code fonctionne comme prévu. Vos clients sont-ils satisfaits du code de buggy? NON!
Tous les bugs ne veulent pas perdre de l'argent du produit. Vous pouvez toujours le réparer lorsque vous le voyez ou quand il vous sera soumis par un autre. Si vous êtes très bon, vous minimisez considérablement le risque. Je sais que vous êtes en colère et que vous ne pouvez pas croire que quelqu'un peut être aussi bon, mais il existe de très bons programmeurs qui ont des bogues à risque zéro, ce qui signifie que les bugs qu'ils font n'affectent pas la gagnante du produit. C'est une chose raisonnable à conclure.
Les tests unitaires servent également à documenter votre base de code, de savoir comment utiliser / appeler une classe / méthode particulière.
Je dirais que le temps d'écrire des tests d'unité automatisés varie en fonction de votre langue et de la façon dont vous faites votre développement. Par exemple, l'écriture C # avec un style très procédural peut conduire à des tests difficiles à développer. Toutefois, si vous prenez une approche différente, dites d'utiliser des cadres moqueurs et des COI, le temps de test unitaire peut être considérablement réduit.
Je suppose que cela dépend ... sur quelle quantité de couverture de test ciblez-vous
Si vous avez l'intention de suivre la définition réelle de TDD où chaque ligne du code est testée via des cas de test unitaire, vous pouvez rechercher un effort énorme
mais il n'est pas nécessaire que
Vous pouvez trouver votre propre équilibre ...
Dans mes expériences, je n'ai pas trouvé cela pour doubler le temps - bien que cela ajoutent un facteur (20-25%?)
Je veux dire- même si vous n'aviez pas de cas de test unitaire, vous feriez toujours un test d'unité manuellement, c'est-à-dire?
Au cours du temps du projet, vous verrez que le temps passé sur des cas de test unitaire est recuré assez facilement
pour les projets clients- IMHO OUI. Ils apprécieront, espérons-ils que l'effort
sur le sujet de l'heure supplémentaire, puisque vous avez mentionné que vous êtes un débutant: le plus tôt vous pouvez trouver une suite de test unitaire qui correspond à vos besoins, mieux c'est. Vous n'avez pas mentionné la langue que vous utilisez, mais s'il n'y a pas de support à la réflexion (C, C ++, par exemple), il faudra généralement beaucoup plus de temps pour mettre en place les installations de test de l'unité, car vous devez instancier le TestSuite, et le test, et vous devez enregistrer le test, etc. C'est tout ce qui est beaucoup de choses à apprendre lorsque tout ce que vous voulez faire est d'exécuter quelques tests!
D'autre part, si vous utilisez une langue plus dynamique comme Python, par exemple, vous pouvez par exemple configurer des tests d'unité avec pratiquement aucune connaissance des tests d'unité en faisant quelques En ce qui concerne la deuxième question, mettez-vous à la place du client - ne voudriez-vous pas savoir que le produit que vous avez acheté a été minutieusement testé? Ils (probablement) des nombres d'amour! Dites-leur que vous avez mis en place des tests automatisés, plus de 500 tests individuels sont exécutés, plus de 80% du code a été testé de cette manière - bien, ne leur dit que la vérité, mais vous obtenez le point. Il ajoute une valeur immense dans la manière de la confiance du code et je préférerais franchement faire des affaires avec une personne qui peut démontrer qu'ils savent ce qui a été testé et ce qui pourrait être squaly, plutôt que quelqu'un qui vient de Mains moi quelque chose et dit "Ça fait" testxxx Méthodes avec le module Unittest .
De bonnes perspectives, merci d'avoir répondu à la deuxième question.
En parlant de l'expérience ici et que vous êtes les bienvenus.
Ce que vous testez déterminera combien de temps il faut. Par exemple, cela me prend beaucoup plus de temps pour écrire un test de l'unité pour TSQL à l'aide du cadre de test de l'unité de base de données à partir de la SM qu'elle n'a pris pour écrire la procédure stockée, car il s'agit d'un processus très manuel pour préparer le test.
Mais, si j'utilise Eclipse ou VS2008 pour les classes Java ou C #, et je viens de le dire de créer les tests, il est assez rapide de faire les tests, autant que le travail grogneur est fait pour moi.
Cela vaut toujours la peine, car il est utile de réduire certains bugs probables, mais plus important encore, lorsqu'il s'agit de faire dupliquer un bug, vous finirez de temps à écrire ces tests, et si vous ne concevez pas votre Les classes doivent être testables, alors il nécessitera un refactoring, qui peut introduire de nouveaux bugs, afin de corriger un bogue signalé.
C'est une chose importante, c'est que vous constaterez que vous avez des fonctions qui ne sont pas testables, vous finirez donc de refactoriser pour que vous puissiez faire des tests d'unités raisonnables.
Par exemple, si vous avez une fonction qui sélectionne à partir d'une base de données, une logique commerciale sur les résultats, comment testez-vous correctement cela? Il devrait s'agir de deux fonctions distinctes, avec un contrôleur qui appelle à la récupération des données, puis appelle à la logique commerciale. Vous aurez donc trois tests, mais le contrôleur peut accéder à une simule pour la base de données car vous avez un test séparé. Pour tester la couche de base de données.
Pour ma programmation, j'ai tendance à tester que des parties du code que je ne peux pas regarder intuitivement et savoir que cela va travailler (que certaines personnes se disputeront ne suffisent pas, mais ce n'est ni ici ni là).
J'ai programmé de cette façon une longue période et que j'utilise ces tests pour m'aider à écrire mon code en premier lieu. Étant donné que, le temps d'écrire mes tests ajoutez, essentiellement, rien à mon temps de développement général. Si j'ai sauté écrit les tests, je le fais "pourrait" sauvegarder 10% de mon temps dans l'ensemble, si cela.
Lorsque j'ai commencé à utiliser des tests automatisés, je dirais qu'un doublement sur le temps global pour écrire du code est une estimation juste. Mais au fil du temps, je suis arrivé à l'endroit où je ne suis pas (ajoutant à côté de rien). Honnêtement, c'est quelque chose que vous vous habituez et cela fait partie de la façon dont vous concevez votre code en premier lieu.
Edit: Il m'est arrivé d'ajouter qu'il y a des moments où écrire le code de test ajoute toujours une juste quantité de temps à mon codage, parfois bien plus que le double. Cela étant dit, ces temps sont rares entre eux, car j'ai tendance à éviter le code qui le fait ... c'est un code sent pour moi.
Si vous êtes sérieux sur les tests unitaires, je recommanderais le livre L'art du test de l'unité par
Ecrire des tests de l'unité (codage) pour votre application double efficacement le Temps de développement requis pour projets.
Les tests d'écriture sont définitivement plus lents que de ne pas écrire de tous les tests si vous comptez simplement le code de frappe de temps. Toutefois, si vous avez pris un compte à temps pour casser la fonctionnalité existante - la fixation de débogage sans le filet de sécurité des tests, les avantages dépasseront généralement les coûts de tout autre que des projets triviaux. Les tests vous aident avec la conception (TDD) + défense (régression) + documentation (spécifications).
est-ce vrai, en particulier pour débutants?
Cela dépend. Pour paraphraser Beck (je pense), si vous êtes un Dunce, des outils / Meth ne vous aideront pas, si vous êtes codant, vous n'en avez probablement pas besoin. Cependant, pour la plupart d'entre nous au milieu, cela aide. Au fur et à mesure que vous vous dirigez vers la droite sur ce spectre, les choses deviennent une seconde nature pour vous, vous devez «voir» ce qui est à venir et que le temps a commencé à réduire (bien que pas à 0). Pour éviter de faire des erreurs de recrue, trouvez quelqu'un qui a déjà été là (Obtenez de l'aide d'une liste de diffusion ou d'embaucher un bon entraîneur pendant un moment)
Aussi quelques questions de suivi (points de brownie): Si vous faites un projet client qui Vous remettez lorsque vous avez terminé, cela vaut-il la peine de faire des tests d'unité?
Même si la prochaine équipe a chucké la suite de tests, je le ferais toujours pour maintenir ma productivité et réduire le temps passé à créer et à poursuivre des bugs.
+1. La première partie résumait ce que je voulais ajouter à la réponse d'Andrew Hare. Au fur et à mesure que le projet devient plus gros, les tests d'unités pour faciliteraient considérablement les tests et le débogage. Le temps de développement est plus long sans tests d'unités pour des projets non triviaux.
"Pour paraphraser Beck (je pense), [...]": Oui c'était Beck, dans l'introduction de TDD par exemple . Je l'ai lu il y a deux jours mais semble être quelque chose que vous vous souvenez plus longtemps :)
pas si vous utilisez TDD parce que:
Vous écrivez en réalité votre test en premier. Ceci est lui-même est un grand épargnant, car vous avez posé ce que vous déconnectez à faire. Vous savez également exactement quand arrêter de coder. (Lorsque le test passe)
Lorsque vous écrivez le code, il est aussi petit que possible. Vous pouvez arrêter de coder lorsque vous passez le test et vous pouvez ensuite le rendre mieux tant que le test est toujours en train de passer.
puis écrivez des tests pour les cas de bord (si nécessaire) et vérifiez que les problèmes seraient des problèmes.
Je l'ai fait et j'ai trouvé que cela réduit le temps de développement - parce que vous avez déjà pensé à ce que vous voulez faire avant même de commencer à écrire le code actuel et que vous savez quand vous l'avez fait travaille réellement.
dépend de l'avantage que vous obtenez. Il s'agit d'une perte de temps complète pour les applications Web conventionnelles - Les clients vont chier plus sur les interfaces d'interface utilisateur, plutôt que du code de corruption lentement.
Merci pour les réponses jusqu'à présent. Désolé j'ai oublié d'ajouter que la langue que j'utilise est PHP et un cadre CakePHP. Cependant, je voulais que cela soit plus d'une question générale pour obtenir une variété de réponses. Je suis également intéressé par l'apprentissage de rubis et de l'objectif-c.