Utilisation des classes Assert
Mise à jour : novembre 2007
Utilisez les classes Assert de l'espace de noms UnitTestingFramework pour vérifier des fonctionnalités spécifiques. Une méthode de test unitaire exerce le code d'une méthode dans votre code de développement, mais elle fournit des rapports sur des aspects du comportement du code uniquement si vous incluez des instructions Assert.
.gif "Remarque") Remarque : |
|---|
Avec ou sans instructions Assert, les tests unitaires peuvent générer des données de couverture du code. Pour plus d'informations, consultez Comment : obtenir des données de couverture du code. |
Types d'Asserts
L'espace de noms Microsoft.VisualStudio.TestTools.UnitTesting fournit plusieurs types de classes Assert :
Dans votre méthode de test, vous pouvez appeler un nombre quelconque de méthodes de la classe Assert, telle que Assert.AreEqual(). La classe Assert offre de nombreuses méthodes et une grande partie d'entre elles a plusieurs surcharges.
Utilisez la classe CollectionAssert pour comparer des collections d'objets et pour vérifier l'état d'une ou plusieurs collections.
Utilisez la classe StringAssert pour comparer des chaînes. Cette classe contient diverses méthodes utiles telles que StringAssert.Contains, StringAssert.Matches et StringAssert.StartsWith.
L'exception AssertFailedException est levée à chaque fois qu'un test échoue. Un test échoue s'il atteint son délai d'expiration, s'il lève une exception inattendue ou s'il contient une instruction Assert qui produit un résultat Échec.
L'exception AssertInconclusiveException est levée à chaque fois qu'un test produit un résultat Non concluant. En général, vous ajoutez une instruction Assert.Inconclusive à un test sur lequel vous travaillez encore, afin d'indiquer qu'il n'est pas encore prêt à être exécuté.
| Remarque : |
|---|
Une autre stratégie consiste à marquer un test qui n'est pas prêt à être exécuté avec l'attribut Ignore. Toutefois, l'inconvénient est qu'il est difficile de générer un rapport sur le nombre de tests qu'il reste à implémenter. |
Si vous écrivez une nouvelle classe d'exceptions Assert, faites en sorte que cette classe hérite de la classe de base UnitTestAssertException afin de simplifier l'identification de l'exception comme échec d'assertion plutôt qu'exception inattendue levée à partir de votre test ou code de production.
Décorez une méthode de test avec l'attribut ExpectedExceptionAttribute lorsque vous souhaitez qu'elle vérifie qu'une exception qui doit être levée par une méthode dans votre code de développement est en effet levée dans cette méthode.
Surcharge de types Unsafe avec Assert.AreEqual
La méthode Assert.AreEqual a de nombreuses surcharges qui vous permettent de comparer des types de données spécifiques. Toutefois, la méthode Assert.AreEqual n'a pas de surcharge pour les types unsafe tels que le type de données pointeur.
Pour illustrer cela, créez une application console C# qui contient la classe suivante :
unsafe public class CUnsafeTest
{
private int* m_pX = null;
unsafe public void VoidPtr(void* voidPtr)
{
}
unsafe public int* ReturnPointer(float* fPtr, TestThis* pTestThis)
{
int x = 5;
return &x;
}
}
Maintenant, générez des tests pour la classe CunsafeTest. Pour plus d'informations, consultez Comment : générer un test unitaire. Du code semblable au suivant sera généré :
[TestMethod()]
public void ReturnPointerTest()
{
unsafe
{
CodeGen.BVT.Unsafe.CUnsafeTest target;
target = new CodeGen.BVT.Unsafe.CUnsafeTest();
// TODO: Initialize to an appropriate value
System.Single* fPtr = null;
// TODO: Initialize to an appropriate value
TestThis* pTestThis = null;
// TODO: Initialize to an appropriate value
System.Int32* expected = null;
System.Int32* actual;
actual = target.ReturnPointer(fPtr, pTestThis);
Assert.AreEqual(actual, expected);
// On the preceding line, no overload is available.
}
}
Dans ce cas, vous devez remplacer l'instruction Assert.AreEqual par votre propre code de vérification personnalisé.
Voir aussi
Concepts
Infrastructure de test unitaire