Je travaille actuellement sur un rapport mensuel sur les comptes créditeurs. Ce rapport que je viens d'écrire sera la base pour mon client dans lequel il va payer à ses fournisseurs. Jusqu'à présent, j'ai passé environ 5 heures à construire des tests automatisés et trouvé zéro erreur jusqu'à présent. Pensez-vous que je passe déjà trop de temps à tester? Quel devrait être le délai idéal pour tester?Quel est le délai idéal pour tester le code
Il n'y a pas de montant « exact » de chiffres doivent être consacrés à écrire des codes d'essai après avoir écrit la spécification de la fonction. Puisque vous avez créé plusieurs cas de test et que vous rencontrez des erreurs minimum/zéro jusqu'à présent, je dirais que vous êtes sur la bonne voie. Ces scénarios de test joueront le rôle de «filet de sécurité» lorsque vous ajouterez d'autres codes ou que vous refactoriserez des codes existants.
Je me souviens d'avoir vu des statistiques illustrant le pourcentage de temps passé à tester différents projets. Il variait généralement d'environ 30% à 50% du temps de développement total, les plus petits projets prenant un pourcentage plus faible. Ceci est cohérent avec mon expérience aussi.
Cordialement
Merci, mais que voulez-vous dire par 30%/50%? – drikoda
Je suppose qu'il voulait dire 30% du temps passé à coder. Donc, si vous avez passé 10 heures à coder, vous devriez passer 3 heures à tester. Je ne suis pas sûr d'être d'accord. –
Idéalement, vous devriez passer le moins de temps possible à écrire des tests, ce qui signifie que votre code devrait être testable en utilisant des tests simples et simples, et vous y parvenez en réduisant Cyclomatic complexity de votre code. Essayez donc de vous concentrer sur l'écriture de code qui nécessite le moins de tests unitaires possible, un cône simple et propre avec une faible complexité cyclomatique. Il n'y a pas de ration horaire standard pour le temps passé à écrire des tests ou du code, la seule mesure est la couverture de test, si votre code est simple, vos tests unitaires seront aussi simples et nécessiteront moins de tests donc moins le temps passé à écrire des tests unitaires sera dépensé.
Avant qu'il ne devienne non-trivial de commencer à tester votre code.
Je commence généralement à tester une fonctionnalité dès que je l'ajoute.
J'essaye de ne pas tester mon code avec autre chose que des tests automatisés. Quand je construis ma fonction, au lieu de l'essayer à la main pendant que je la construis, je l'essaie avec des tests. De cette façon, ce n'est pas plus de travail que ce que vous auriez fait de toute façon, et vous avez les tests par la suite. Après cela, j'ajoute des tests lorsque je découvre des bogues, ou de temps en temps pour couvrir des bogues que je pense pourraient être ajoutés par un mainteneur négligent. L'idée est de tester pour vous aider, ne pas vous mettre en travers de votre chemin!
Il n'y a pas de temps fixe à consacrer aux tests. C'est un peu comme demander "combien de temps est approprié pour écrire une fonctionnalité?" Cela dépend vraiment de la complexité de l'article écrit et de la largeur de la surface. Plus l'utilisateur peut faire avec votre outil, plus vous devriez le tester.
Les tests de tout ce qui concerne l'utilisateur final doivent être de deux types: 1) Test automatisé. Tests de régression, tests unitaires, etc. 2) Tests manuels. Attendez que vous ayez fini, puis essayez de frapper tous les coins comme le ferait l'utilisateur. Vous ne couvrirez pas tout dans vos tests automatisés et vous ne remarquerez peut-être pas d'effets secondaires, donc vous aurez besoin d'un œil humain avant d'expédier. Plutôt que de décider combien de temps il faut consacrer aux tests, décidez ce que vous pensez qu'il faut tester et dépenser le temps nécessaire.
Mais pour vos propres tests avez-vous un délai précis? – drikoda
@drikoda: généralement, chaque fois que je crée une fonction ou des méthodes, je crée habituellement directement des cas de test pour tester ces nouvelles fonctions ou méthodes. Plus les fonctions ou les méthodes à tester sont petites, plus il est facile de détecter les bogues antérieurs, avant qu'ils ne deviennent compliqués lorsqu'ils sont combinés à d'autres fonctions ou méthodes. Et plus les fonctions ou les méthodes sont petites, nous pouvons nous assurer que le principe de responsabilité unique est appliqué, et nous pouvons le rendre robuste et bien testé. –