Quel est exactement un test unitaire et comment puis-je écrire un? J'entends plusieurs fois que les gens les écrivent avant même que leur application ne soit même écrite, comment cela peut-être? Je suis sous l'impression qu'un test unitaire est un code qui appelle une méthode de votre application avec une valeur définie et attend une valeur spécifique à revenir, si la valeur spécifique ne revient pas, le test a échoué. Est-ce que je me trompe ou induire en erreur ici? J'ai tellement lu sur les tests unitaires, mais je sais très peu de ce qu'il ressemble à ce qu'il ressemble au code de sorte qu'un échantillon serait génial.
est-ce un test unitaire? P>
Démarrer le code PSEDEDO ...
CheckForDuplicateSubdomains(){
get all users in DB with matching subdomains
if greater than zero, fail test
}
6 Réponses :
Je suis sous l'impression qu'un test unitaire est un code qui appelle une méthode de votre application avec une valeur définie et attend une valeur spécifique à revenir, si la valeur spécifique ne revient pas le test a échoué. . Je me trompe ou induire en erreur ici?
Nope, vous avez exactement raison.
La chose importante avec des tests unitaires consiste à tester un petit morceau de code que possible.
Dans votre exemple, vous obtenez quelque chose de la DB, puis comptez le nombre d'articles ... Si votre méthode échoue, vous ne saurez jamais exactement où les choses ont mal tourné parce qu'il y a tellement de choses qui pourraient mal aller mal ... .
Votre connexion DB pourrait être perdue, SQL non valide, ...
Si vous utilisez ASP.NET MVC, vous devez avoir des tests d'unité de rédaction temporelle plus faciles que si vous utilisiez la normale ASP.NET
Un test unitaire est un test qui exerce une très petite partie de votre code, généralement une seule méthode (une unité à exiger).
Dans TDD, les développeurs sont capables d'écrire le test de l'unité avant de coder la méthode car elles savent déjà quelle unité de code devrait faire. Peu importe la façon dont il fait le travail ... le test s'assure simplement que les résultats sont corrects.
et ce pseudo-code pourrait être utilisé comme test unitaire (pas sûr de ce que ce serait tester, mais je devrais supposer que vous testez une méthode qui ne devrait pas renvoyer des sous-domaines en double).
La théorie est le test unitaire (et le développement axé sur les tests) devrait atténuer les maux de tête en bas de la route en veillant à ce que chaque unité de code soit exactement ce qu'on attend.
Vous êtes correct sur les tests unitaires. L'idée est de tester toutes vos fonctions, une par une, avec des entrées différentes pour vous assurer qu'ils travaillent comme si vous attendez (par opposition à la découverte après avoir été insérée dans une application. Ensuite, puis effectuant les tests plus compliqués).
Écrire les tests de l'unité Avant d'écrire la fonction fait partie d'une méthodologie appelée "Développement piloté par tests". Dans lequel vous écrivez uniquement le squelette de la fonction et que toute l'unité teste d'abord. Donc, au début, tous vos tests échoueront (B / C, la fonction n'est pas encore programmée). Après cela, vous programmez la fonction jusqu'à ce que tous les tests passent.
TDD implique la rédaction d'un seul test de l'unité, puis le code pour le faire passer, puis refactorise ce code pour le nettoyer, puis répéter avec un nouveau test d'unité. Vous n'écririez pas de tasse de tests, puis un tas de code comme vous semblez impliquer.
Je ne pense pas que TDD exclut d'écrire plus d'un test à la fois, bien que je ne suis peut-être pas ignorant à ce sujet. Par exemple, si la fonction doit faire deux choses - par exemple, insérez une ligne dans une base de données et renvoyez le numéro de ligne. Cela pourrait nécessiter deux tests, un pour tester que la ligne est entrée et un deuxième test pour indiquer que le numéro de ligne est correct. Bien sûr, vous pouvez faire les deux validations dans un seul test, mais à ce stade, nous divisons les cheveux sur la définition de ce qui constitue un seul test.
Oui, votre exemple serait un test unitaire. Il y a quelques raisons de créer d'abord le test. Premièrement, il agit en tant que documentation vivante pour votre projet. Il établit des comportements et des résultats attendus, ce qui devrait vous aider à mettre en œuvre votre code (il est plus facile d'écrire quelque chose, de savoir ce qu'il faut faire et fondamentalement comment il est initié). Deuxièmement, si vous écrivez le test après, vous êtes plus susceptible d'écrire un test qui fonctionne avec le code que vous avez déjà écrit, ce qui ne vous aide pas. Définissez quelle unité de code doit faire, écrire les tests et écrire / corriger le code afin de refléter les comportements dans les tests. Cette stratégie se traduit par une meilleure compréhension et une qualité lorsque votre demande évolue.
Les tests d'unités sont des tests automatisés au niveau de l'unité. Par niveau unitaire, ils signifient une unité de code atomique de telle sorte que vous ne puissiez pas la casser plus loin. une fonction ou une partie particulière d'un objet. Un test d'unité pour une fonction carrée ressemblerait à quelque chose comme Vous pouvez maintenant écrire cela dès que vous avez décidé sur l'interface de carré, pour une fonction plus compliquée que vous pourriez mesurer à quel point Terminer la fonction est par le nombre de tests passés.
Il existe des conventions très bien établies pour les tests d'unités dans la famille des cadres de Xunit, dérivés à l'origine de Junit. Dans ce cadre, l'assertion em> est le véhicule principal pour passer un test. Dans une suite d'essai, l'objectif est de faire en sorte que 100% de vos affirmations soient vraies. considère votre exemple. P> Ce test aurait conventionnellement un nom à partir de "Test", qui permet au Coureur de test du cadre savoir que cette fonction est un test et non une méthode de configuration, par exemple. Il est important d'être clair que nous testons le comportement du code et non l'état des données em>. p> dans chaque test, il y a quatre Phases : P> Le SUT est le "Système sous test", qui est typiquement une méthode d'une classe dans votre code de production. P>
testNoDuplicateSubdomains(){
// fixture setup
prepareDatabaseTestData()
// exercise SUT,
SUT = new ProductionObject()
result = SUT.getAllUsersWithMatchingSubDomains()
// result verification and
assertEmpty(result) // or whatever makes sense
// fixture teardown.
removeDatabaseTestData()
}
Il semble que la fausse mesure est une idée fausse dans l'exemple de Checkforduplicatesubdomains () en ce sens qu'elle semble être inclinée vers la vérification de l'état de certaines données plutôt que du comportement d'un bloc de code. Même si j'ai porté cela dans mon exemple modifié, je pense que la discussion est toujours informative. En terminant, je recommanderais qu'un débutant préfère acquérir des expériences de construction de tests d'unité dans un morceau du code qui n'est pas proche de la base de données. L'interface de base de données de code est une pièce notoirement gênante à un test unitaire.
Je recommande également de lire les réponses à la question "Comment puis-je lancer des tests unitaires?" Stackoverflow.com/Questtions/1300157/Commander- DO-I-START-UNIT-TEST-TEST ING .