Assertions de MSTest

Utilisez les classes Assert de l’espace de noms Microsoft.VisualStudio.TestTools.UnitTesting pour vérifier une fonctionnalité spécifique. Une méthode de test exerce le code dans votre application, mais signale l’exactitude uniquement lorsque vous incluez des Assert instructions.

Aperçu

MSTest fournit trois classes d’assertion :

classe Objectif
Assert Assertions à usage général pour les valeurs, les types et les exceptions.
StringAssert Assertions spécifiques à la chaîne pour les modèles, les sous-chaînes et les comparaisons.
CollectionAssert Assertions de collection pour comparer et valider des collections.

Important

Pour le nouveau code, utilisez toujours la Assert classe. Les classes StringAssert et CollectionAssert seront probablement rendues obsolètes dans une prochaine version. Ils sont conservés principalement pour la compatibilité descendante, mais ils ne sont pas recommandés, car le fractionnement des assertions sur trois types nuit à la détectabilité.

Toutes les méthodes d’assertion acceptent un paramètre de message facultatif qui s’affiche lorsque l’assertion échoue, ce qui vous aide à identifier la cause :

Assert.AreEqual(expected, actual, "Values should match after processing");

La classe Assert

Utilisez la classe Assert pour vérifier que le code sous test se comporte comme prévu.

Méthodes d’assertion courantes

[TestMethod]
public async Task AssertExamples()
{
    // Equality
    Assert.AreEqual(5, calculator.Add(2, 3));
    Assert.AreNotEqual(0, result);

    // Reference equality
    Assert.AreSame(expected, actual);
    Assert.AreNotSame(obj1, obj2);

    // Boolean conditions
    Assert.IsTrue(result > 0);
    Assert.IsFalse(string.IsNullOrEmpty(name));

    // Null checks
    Assert.IsNull(optionalValue);
    Assert.IsNotNull(requiredValue);

    // Type checks
    Assert.IsInstanceOfType<IDisposable>(obj);
    Assert.IsNotInstanceOfType<string>(obj);

    // Exception testing (MSTest v3.8+)
    Assert.ThrowsExactly<ArgumentNullException>(() => service.Process(null!));
    await Assert.ThrowsExactlyAsync<InvalidOperationException>(
        async () => await service.ProcessAsync());
}

API disponibles

La classe StringAssert

Utilisez la classe StringAssert pour comparer et examiner des chaînes.

Avertissement

La StringAssert classe est susceptible d’être déconseillée dans une version ultérieure. Il est conservé uniquement pour la compatibilité descendante et n’est pas recommandé pour le nouveau code. Toutes les StringAssert méthodes ont des équivalents sur la Assert classe, ce qui offre une meilleure détectabilité. Pour migrer les utilisations existantes, consultez l’analyseur MSTEST0046.

Les API disponibles sont les suivantes :

La classe CollectionAssert

Utilisez la classe CollectionAssert pour comparer des collections d’objets ou pour vérifier l’état d’une collection.

Avertissement

La CollectionAssert classe est susceptible d’être déconseillée dans une version ultérieure. Il est conservé principalement pour la compatibilité descendante et n’est pas recommandé pour le nouveau code. Lorsqu’une méthode équivalente existe sur Assert (comme Assert.Contains, Assert.DoesNotContain ou Assert.HasCount), utilisez Assert pour une meilleure visibilité.

Les API disponibles sont les suivantes :

Créer des assertions personnalisées avec Assert.That

Les méthodes d’assertion intégrées ne couvrent pas tous les scénarios. Pour étendre l’infrastructure d’assertion avec vos propres vérifications, MSTest met à disposition la propriété singleton Assert.That comme point d’extension. Vous ajoutez des assertions personnalisées en tant que méthodes d’extension C# sur le Assert type d’instance, et les appelants les appellent avec la syntaxe familière Assert.That.MyAssertion(...) .

Pour une meilleure détectabilité, organisez les assertions à l’échelle du projet dans une classe statique dédiée. Les assertions personnalisées accessibles via Assert.That s’affichent aux côtés des méthodes intégrées dans IntelliSense, afin que les utilisateurs n’aient pas à se souvenir d’un type d’assistance distinct.

Créer une assertion personnalisée

Ajoutez une méthode d’extension qui cible le Assert type et lève AssertFailedException lorsque la condition échoue :

using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

public static class CustomAssertExtensions
{
    public static void IsPrime(this Assert assert, int value)
    {
        if (value < 2 || Enumerable.Range(2, (int)Math.Sqrt(value) - 1).Any(i => value % i == 0))
        {
            throw new AssertFailedException($"Assert.That.IsPrime failed. Value <{value}> is not a prime number.");
        }
    }
}

Utiliser une assertion personnalisée

Après avoir importé l’espace de noms qui contient vos méthodes d’extension, appelez votre assertion personnalisée via Assert.That:

[TestMethod]
public void Compute_ReturnsPrime()
{
    int result = _calculator.NextPrime(10);
    Assert.That.IsPrime(result);
}

Raccordements d’extension sur StringAssert et CollectionAssert

Les propriétés StringAssert.That et CollectionAssert.That exposent le même modèle singleton pour assurer la rétrocompatibilité. Pour les nouvelles assertions personnalisées, ciblez toujours Assert.That. Dans le cas contraire, vos fonctions utilitaires hériteront des mêmes problèmes de facilité à être trouvées que les anciennes classes, et elles devront être migrées si StringAssert et CollectionAssert deviennent obsolètes.

Assert.That propriété et Assert.That(...) méthode

Note

Ne confondez pas la Assert.Thatpropriété singleton utilisée comme hook d’extensibilité, avec la Assert.That(() => condition)méthode ajoutée dans MSTest 3.8. Ce dernier accepte une expression booléenne et produit des messages d’échec détaillés en analysant l’arborescence d’expressions (par exemple). Assert.That(() => order.Total > 0) Les deux API partagent un nom, mais servent des objectifs différents.

Meilleures pratiques

  • Utilisez des assertions spécifiques : préférez AreEqual à IsTrue(a == b) pour de meilleurs messages d’échec.

  • Inclure des messages descriptifs : aidez à identifier rapidement les échecs avec des messages d’assertion clairs.

  • Testez une chose à la fois : chaque méthode de test doit vérifier un comportement unique.

  • Utiliser Throws/ThrowsExactly pour les exceptions : dans MSTest v3.8+, préférez Assert.Throws, Assert.ThrowsExactlyet leurs équivalents asynchrones (ThrowsAsync, ThrowsExactlyAsync) sur l’attribut ExpectedException .

  • Assert StringAssert /Préférez CollectionAssert: pour une meilleure détectabilité et cohérence, utilisez la Assert classe. Les classes StringAssert et CollectionAssert seront probablement obsolètes dans une future version.

  • Étendre Assert.That pour les assertions personnalisées : pour une détectabilité cohérente, ajoutez des assertions personnalisées en tant que méthodes d’extension et Assert appelez-les via Assert.That. Ne ciblez pas StringAssert.That ni CollectionAssert.That dans le nouveau code.

Les analyseurs suivants permettent de garantir une utilisation appropriée des assertions :

  • MSTEST0006 - Évitez l’attribut ExpectedException , utilisez Assert.Throws plutôt des méthodes.
  • MSTEST0017 : les arguments d’assertion doivent être passés dans l’ordre correct.
  • MSTEST0023 - Ne pas nier les assertions booléennes.
  • MSTEST0025 - Préférez Assert.Fail plutôt que les conditions toujours fausses.
  • MSTEST0026 : les arguments d’assertion doivent éviter l’accès conditionnel.
  • MSTEST0032 : passez en revue les conditions d’assertion always-true.
  • MSTEST0037 - Utilisez des méthodes d’assertion appropriées.
  • MSTEST0038 - Évitez Assert.AreSame avec les types valeur.
  • MSTEST0039 : utilisez des méthodes plus récentes Assert.Throws .
  • MSTEST0040 - Évitez d’utiliser des assertions dans un contexte void asynchrone.
  • MSTEST0046 - Utiliser Assert au lieu de StringAssert.
  • - Assert.Throws MSTEST0051 doit contenir une instruction unique.
  • MSTEST0053 : évitez les Assert paramètres de format.
  • MSTEST0058 : évitez les assertions dans les blocs catch.

Voir aussi

  • Last updated on