Cette question pourrait être légèrement vague mais voilà. Je viens de démarrer des tests unitaires et je semblais avoir du mal à la notion de base.
Je teste une fonction qui vérifie si un enregistrement existe dans la base de données. Sinon, il ajoute le nouvel enregistrement et renvoie son identifiant. Donc, la fonction est simple à écrire. Et la seule façon de penser à tester consiste à utiliser le cadre moqueur pour vérifier que les bonnes propriétés / méthodes étaient appelées le bon nombre de fois.
La pièce avec qui je suis en difficulté, c'est que tout ce que j'ai jamais lu pour parler des tests d'écriture d'une part, puis de la fonction. Mais je me sens comme ça ne marchera que si j'écris la fonction d'abord, puis écrivez des tests qui reflètent le fonctionnement intérieur des fonctions.
y a-t-il vraiment une règle d'or pour cela?
Et combien devrais-je tester la logique transactionnelle de base quand même?
6 Réponses :
Peut-être que si vous voulez développer à ce niveau, vous pouvez écrire d'abord le contrat de la méthode et que le test en fonction du contrat. Il est important que votre méthode se comporte comme définie dans le contrat, car c'est ce que les autres développeurs s'attendent. Surtout les cas de bord (exceptions et ainsi de suite) devraient être testés.
Si vous allez changer votre contrat tout en développant la méthode, ce n'est pas bon. Parce que vous n'avez pas planifié votre logiciel et aussi, vous pouvez réécrire vos tests =)
Test est important car lorsque vous effectuez des modifications de code, vous pourrez plus facilement détecter les erreurs avec les tests sauvegardés, lorsque vous vous épargnez quelque chose, en essayant de développer quelque chose de nouveau.
Cela m'a fait penser le long du bon chemin. La façon dont j'ai interprété c'était "définir les entrées et les sorties et écrire les tests pour cela". Est-ce à propos de vrai? Dans d'autres mots-bas, je ne devrais pas m'inquiéter du fonctionnement interne de la méthode.
Autant que je sache, je dirais que vous devriez toujours garder à l'esprit comment vous allez tester la fonction, mais le code de la fonction elle-même. Cela vous permettra de localiser des pièces critiques et des bugs éventuels pouvant survenir. Vous pouvez également tester les sorties / entrées de votre fonction et vous assurer qu'ils correspondent aux résultats souhaités - le test de la boîte noire fonctionne bien avec ce test d'unité de pré-codage.
J'ai également eu du mal avec cette idée d'écrire des tests d'unité avant de coder votre méthode réelle. N'oubliez pas que je ne suis qu'un étudiant et c'est juste mon avis.
J'espère que cela aide, j'espère avoir raison :)
La partie dont j'ai du mal, c'est que partout où j'ai déjà lu des discussions sur les tests d'écriture d'une part, puis de la fonction. Mais je me sens comme ça ne marchera que si j'écris la fonction d'abord, puis écrivez des tests qui reflètent les travaux internes des fonctions.
On dirait que vous souffrez du problème de poulet / oeuf commun avec Développement axé sur les tests (TDD). Vous ne savez pas ce que vous voulez tester jusqu'à ce que vous ayez du code et que vous croyez que vous ne pouvez pas faire TDD à moins que vous n'ayez rédiger des tests avant de coder.
C'est vraiment un cas de bloc de concepteur (TM). Tout comme le bloc de l'écrivain, il est souvent bon de travailler en codant - même si vous lancez tout ce code.
pirater un prototype, puis prétendez que cela n'existe pas. (Ne l'expédiez pas :) Ce prototype doit explorer les concepts que vous n'avez pas connus, ou n'avez pas suffisamment d'informations pour commencer à concevoir. Cela devrait vous familiariser avec le problème afin que vous puissiez commencer à concevoir.
Après avoir une preuve de concept, CODE Review le diable en dehors de celui-ci. Dans votre révision, déterminez ce que vous voulez que l'interface publique ressemble à ce que les modèles architecturaux conviennent au mieux au programme et quelles dépendances doivent être isolées les unes des autres (et se moquer de vos tests). Prenez des notes ou soumettez des exigences dans votre logiciel de planification de projet / des éléments de travail dans votre logiciel de suivi de projet.
Si vous avez des problèmes d'identification de ces choses dans votre revue, vous devriez essayer de recruter d'autres programmeurs (et éventuellement des concepteurs / personnes qui identifient vos besoins en entreprise) pour vous aider à traverser. Un mentor de code peut être une bonne idée.
Dans cet examen, vous devriez pouvoir commencer à coder vos tests. Ou vous pouvez commencer à écrire une spécification technique - ce conseil s'applique également bien aux deux.
(Si vous travaillez sur une équipe, des exigences de collecte et obtenez les commentaires de l'utilisateur / effectuant UATS est également requis; mais cela pourrait être le travail de quelqu'un d'autre)
Modifier Gardez à l'esprit que ce n'est qu'une approche pour traiter ce problème. Un autre consiste simplement à détendre tous les idéaux de type puritain sur la manière dont TDD devrait fonctionner et développer simplement vos tests en parallèle avec votre code. Vérifiez-les en même temps.
Il convient également parfaitement à faire des tests unitaires sans TDD. Les tests d'unités confèrent plus d'avantages que de simplement encoder votre conception et vos exigences. Ils sont également une aide énorme lorsque vous ajoutez de nouvelles fonctionnalités ou des bugs fixes (test de régression) ou lorsque vous portez votre code.
La chose importante sur le prototypage est que vous devriez vraiment effacer toute trace du prototype lorsque vous en avez terminé, de sorte que vous n'êtes pas sûr de la copie et de la pâte ou de la pâte de ce type.
et combien dois-je tester la logique transactionnelle de base quand même?
C'est mon expérience plus les tests que vous écrivez, plus vous serez heureux.
Test de la logique transactionnelle de base vous donnera de l'expérience avec vos cours et comment elles interagissent et vous donnent une idée de leur vitesse, et même la manière dont la logique transactionnelle de base fonctionne vraiment.
Cela vous aidera à devenir meilleur lors de la rédaction des cas de test, car la pratique est parfaite.
Et plus tard, qui sait, cela vous aidera à détecter un bogue lorsque vous mettez à niveau votre base de données ou modifiez entièrement des bases de données.
Il y a de bonnes raisons pour l'écriture de tests d'abord:
Dans l'ensemble, il peut se sentir difficile, mais la récompense vaut bien la peine.
Je vais essayer spécifiquement de répondre à votre question sur le test de la logique de base de la transaction. La plupart du temps, j'écris des tests d'unité pour les unités plus élevées dans la hiérarchie. Par exemple, dans une configuration de base du contrôleur de modèles de base, mes tests d'unités testent les contrôleurs et non le DAL sous-jacent. Pourquoi? Parce que je suppose que lorsqu'un contrôleur passe les tests, les couches sous le contrôleur fonctionnent également bien.
Il y a une exception cependant, pour les libs partagés. Les bibliothèques partagées sur de nombreux projets obtiendront leurs propres tests unitaires, par exemple pour assurer la stabilité de l'API.
Aussi, consultez vos tests de l'unité comme une autre application de votre projet. Assurez-vous de ne pas C / P Code dans des tests, ne jetez pas un tas de correctifs de test, mais prenez votre temps pour concevoir une belle structure qui est extensible. Il vous fera économiser beaucoup de temps dans la fonctionnalité.
"Dans une configuration de base du contrôleur de modèles de base, mes tests de l'unité teste les contrôleurs et non le DAL sous-jacent". Si vous ne vous moquez pas du DAL, vous testez les deux. Cela peut utiliser un style d'essai unitaire, mais est en fait plus un test d'intégration, car le stockage qu'elle interagit est également en place. Je crois que l'affiche originale se moque de son dal, auquel cas il aura également besoin d'écrire des tests pour le DAL.
Les tests d'écriture sont d'abord une approche supplémentaire appelée TDD: Stackoverflow.com/Questions/tagged/tdd