Comment écrire des Cas de Test?

Je veux apprendre à écrire des cas de test avant d'écrire le code. J'ai lu un article sur le développement piloté par les tests. Je me demande comment les développeurs à écrire des cas de test? Pour Exemple de cette méthode:

    public int divideNumbers(int num1, int num2)
    {
      return num1 / num2;
    }
vous savez que vous avez déjà écrit le code avant de vos tests? 🙂

OriginalL'auteur cihata87 | 2013-01-03

  1. 4

    Nous commençons avec un projet vide maintenant. Vous voulez faire quelque chose, dire diviser deux nombres. Si vous écrivez un essai décrivant ce que vous voulez faire:

    Assert.That(divide(10,2), Eq(5))

    Ce test vous donne un point d'entrée: il décrit l'acceptable de l'interface de la divide méthode. Si vous passez à la mettre en œuvre comme int divide(int x, int y) par exemple.

    Écrire des tests qui décrivent ce que vous vous attendez à obtenir à partir de votre code. Vous n'avez pas besoin de réfléchir beaucoup à ce sujet. Le plus normal pour l'écriture de vos attente est probablement la meilleure manière de la conception de votre code, et vous pouvez alors mettre en œuvre afin de satisfaire votre test.

    OriginalL'auteur Hosam Aly

  2. 1

    Il y a quelques étapes pour les tests. De MSDN;

    Dans votre cas;

    Assert.AreEqual(divideNumbers(8, 4), 2);

    Assert classe vérifie les conditions dans les tests unitaires à l'aide de true/false propositions. Vous devriez écrire vos cas de test ce qui vous attend à leurs résultats. Vous pouvez utiliser TestMethod attribut pour vos méthodes de test. Il est cool post sur Créer des tests Unitaires pour votre code c# . Analyser très bien.

    En fait ce que je veux demander a une réponse que le lien que vous avez partagé de codeproject. Merci.

    OriginalL'auteur Soner Gönül

  3. 1

    Commencer avec un talon de la fonction/classe/composant que vous souhaitez développer. Il doit compiler, mais délibérément de ne pas (encore) de faire ce qu'il est censé faire.

    Par exemple:

    public int divideNumbers(int num1, int num2)
{
    throw new NotImplementedException();
}

    ou

        return -42;

    Réfléchir sur le comportement voulu, le traitement de la fusée d'une interface à une boîte noire. Ne se soucient pas de la mise en œuvre (encore). Penser le "contrat" de l'interface: X, Y va.

    Identifier le cas standard et important egde cas. Écrire des tests pour eux.

    Pour la division entière (en supposant que nous devons écrire à partir de zéro) il y a vraiment un couple de cas: Avec et sans reste, n/1, n/0, 0/n, 0 à 0, les nombres négatifs, etc.

    Assert.IsTrue(divideNumbers(4,4) == 1);
Assert.IsTrue(divideNumbers(4,3) == 1);
Assert.IsTrue(divideNumbers(4,2) == 2);
Assert.IsTrue(divideNumbers(4,1) == 4);
Assert.Throws<ArgumentException>(() => divideNumbers(4,0));

Assert.IsTrue(divideNumbers(0,4) == 0);
Assert.Throws<ArgumentException>(() => divideNumbers(0,0));

Assert.IsTrue(divideNumbers( 4,-2) == -2);
Assert.IsTrue(divideNumbers(-4, 2) == -2);
Assert.IsTrue(divideNumbers(-4,-2) ==  2);

Assert.IsTrue(divideNumbers( 4,-3) == -1);
Assert.IsTrue(divideNumbers(-4, 3) == -1);
Assert.IsTrue(divideNumbers(-4,-3) ==  1);

    Compiler et exécuter les tests unitaires. Ont-ils tous été un échec? Si non, pourquoi? Peut-être l'un des tests ne fonctionne pas comme prévu (les tests peuvent être buggy, aussi!).

    Maintenant, commencer à mettre en œuvre jusqu'à ce qu'aucun test échoue plus.

    OriginalL'auteur Sebastian Negraszus

  4. 0

    Commencez par réaliser la différence entre la théorie et la pratique.

    Toute la vie réelle système aura des choses qui est facilement créé par TDD, et d'autres qui ne le sont pas.

    Le dernier groupe est tout dépend de l'environnement, lorsque l'on travaille sur un système qui ne cherche pas faire abstraction des hypothèses liées à l'environnement, mais de façon pragmatique accepter.

    Ce groupe peut être développé dans un ATS de la mode, mais il aura besoin de plus d'outillage et d'extensions pour le logiciel de l'usine.

    Pour .Net ce serait de l'outillage et des extensions telles que MS virtual Laboratoire de Test et SpecFlow.

    Ce que j'essaie de communiquer, c'est que ça dépend.

    Pour de très simple composant/tests unitaires, l'idée serait d'écrire un défaut de cas de test, avant d'écrire le code à tester, et se terminant le développement quand le test s'exécute avec succès.

    Pour les tests d'intégration et au-delà (test du système), vous aurez besoin d'examiner, entre autres choses, comment apporter de l'environnement de test dans certains connus de l'état, en plus de tenir compte de ce à test.

    OriginalL'auteur Casper Leon Nielsen