MSTest-Assertionen

Verwenden Sie die Assert-Klassen des Microsoft.VisualStudio.TestTools.UnitTesting-Namespace, um bestimmte Funktionen zu überprüfen. Eine Testmethode führt den Code in Ihrer Anwendung aus, meldet jedoch die Richtigkeit nur, wenn Sie Assert-Anweisungen einschließen.

Überblick

MSTest stellt drei Assertionsklassen bereit:

Class Zweck
Assert Allgemeine Assertionen für Werte, Typen und Ausnahmen.
StringAssert Zeichenfolgenspezifische Assertionen für Muster, Teilzeichenfolgen und Vergleiche.
CollectionAssert Sammlungs assertionen zum Vergleichen und Validieren von Sammlungen.

Von Bedeutung

Verwenden Sie für neuen Code immer die Assert Klasse. Die Klassen StringAssert und CollectionAssert werden in einer künftigen Version voraussichtlich als veraltet gekennzeichnet. Sie werden hauptsächlich aus Gründen der Abwärtskompatibilität beibehalten, aber sie werden nicht empfohlen, da das Aufteilen von Assertionen über drei Typen hinweg die Auffindbarkeit beeinträchtigt.

Alle Assertionsmethoden akzeptieren einen optionalen Meldungsparameter, der angezeigt wird, wenn die Assertion fehlschlägt, und hilft Ihnen dabei, die Ursache zu identifizieren:

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

Die Assert-Klasse

Verwenden Sie die Assert-Klasse, um zu überprüfen, ob sich der Testcode erwartungsgemäß verhält.

Allgemeine Assertionsmethoden

[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());
}

Verfügbare APIs

Die StringAssert-Klasse

Verwenden Sie die Klasse StringAssert, um Zeichenfolgen zu vergleichen und zu überprüfen.

Warning

Die StringAssert Klasse wird in einer zukünftigen Version wahrscheinlich nicht mehr unterstützt. Sie wird nur aus Gründen der Abwärtskompatibilität beibehalten und wird für neuen Code nicht empfohlen. Alle StringAssert Methoden verfügen über Entsprechungen für die Assert Klasse, die eine bessere Auffindbarkeit bietet. Informationen zum Migrieren vorhandener Verwendungen finden Sie unter "Analyzer MSTEST0046".

Verfügbare APIs sind:

Die CollectionAssert-Klasse

Verwenden Sie die Klasse CollectionAssert, um Objektsammlungen zu vergleichen und den Zustand einer Sammlung zu überprüfen.

Warning

Die CollectionAssert Klasse wird in einer zukünftigen Version wahrscheinlich nicht mehr unterstützt. Sie wird hauptsächlich aus Gründen der Abwärtskompatibilität beibehalten und wird nicht für neuen Code empfohlen. Wenn es auf Assert eine entsprechende Methode gibt (wie Assert.Contains, Assert.DoesNotContain oder Assert.HasCount), verwenden Sie Assert für eine bessere Auffindbarkeit.

Verfügbare APIs sind:

Erstellen benutzerdefinierter Assertionen mit Assert.That

Die integrierten Assertionsmethoden decken nicht jedes Szenario ab. Um die Assertionsinfrastruktur mit Ihren eigenen Prüfungen zu erweitern, macht MSTest die Assert.That-Singleton-Eigenschaft als Erweiterungshaken verfügbar. Sie fügen benutzerdefinierte Assertionen als C#-Erweiterungsmethoden für den Assert Instanztyp hinzu, und Aufrufer rufen sie mit der vertrauten Assert.That.MyAssertion(...) Syntax auf.

Zur besseren Auffindbarkeit organisieren Sie projektweite Assertionen in einer dedizierten statischen Klasse. Benutzerdefinierte Assertions, auf die über Assert.That zugegriffen wird, werden in IntelliSense zusammen mit den integrierten Methoden angezeigt, sodass Nutzer sich keinen separaten Hilfstyp merken müssen.

Erstellen einer benutzerdefinierten Assertion

Fügen Sie eine Erweiterungsmethode hinzu, die auf den Typ Assert abzielt und AssertFailedException auslöst, wenn die Bedingung fehlschlägt:

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.");
        }
    }
}

Verwenden einer benutzerdefinierten Assertion

Nachdem Sie den Namespace importiert haben, der Ihre Erweiterungsmethoden enthält, rufen Sie Ihre benutzerdefinierte Assertion über Assert.That auf:

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

Erweiterungs-Hooks bei StringAssert und CollectionAssert

Die Eigenschaften StringAssert.That und CollectionAssert.That stellen aus Gründen der Abwärtskompatibilität dasselbe Singleton-Muster bereit. Bei neuen benutzerdefinierten Assertionen wird immer als Ziel festgelegt Assert.That. Andernfalls erben Ihre Helfer dieselben Auffindbarkeitsprobleme wie die Legacy-Klassen, und sie müssen migriert werden, wenn StringAssert und CollectionAssert als veraltet gekennzeichnet werden.

Assert.That Eigenschaft im Vergleich zu Assert.That(...) Methode

Hinweis

Verwechseln Sie die Assert.ThatSingleton Eigenschaft – die als Erweiterungshaken dient – nicht mit der in MSTest 3.8 hinzugefügten Assert.That(() => condition)Methode. Letztere akzeptiert einen booleschen Ausdruck und erzeugt detaillierte Fehlermeldungen durch Analyse des Ausdrucksbaums (z. B. Assert.That(() => order.Total > 0)). Die beiden APIs geben einen Namen gemeinsam, dienen jedoch unterschiedlichen Zwecken.

Bewährte Methoden

  • Verwenden Sie bestimmte Assertionen: Bevorzugen Sie AreEqual über IsTrue(a == b) für bessere Fehlermeldungen.

  • Beschreibende Nachrichten einschließen: Helfen Sie beim schnellen Erkennen von Fehlern mit klaren Assertionsmeldungen.

  • Testen Sie jeweils eine Sache: Jede Testmethode sollte ein einzelnes Verhalten überprüfen.

  • Verwenden Sie Throws/ThrowsExactly für Ausnahmen: In MSTest v3.8+ sollten Sie Assert.Throws, Assert.ThrowsExactly und deren asynchrone Entsprechungen (ThrowsAsync, ThrowsExactlyAsync) statt des ExpectedException Attributs bevorzugen.

  • Assert gegenüber StringAssert/CollectionAssert bevorzugen: Für bessere Auffindbarkeit und Konsistenz verwenden Sie die Klasse Assert. Die Klassen StringAssert und CollectionAssert werden in einer zukünftigen Version voraussichtlich als veraltet eingestuft.

  • Erweitern Sie Assert.That für benutzerdefinierte Assertionen: Fügen Sie für eine konsistente Auffindbarkeit benutzerdefinierte Assertionen als Erweiterungsmethoden für Assert hinzu und rufen Sie sie über Assert.That auf. Verwenden Sie StringAssert.That oder CollectionAssert.That nicht in neuem Code.

Die folgenden Analysegeräte tragen dazu bei, die ordnungsgemäße Verwendung von Assertionen sicherzustellen:

  • MSTEST0006 – Vermeiden Sie das ExpectedException-Attribut, und verwenden Sie stattdessen die Assert.Throws-Methoden.
  • MSTEST0017 – Assertionsargumente sollten in der richtigen Reihenfolge übergeben werden.
  • MSTEST0023 - Keine booleschen Aussagen verneinen.
  • MSTEST0025 – Bevorzugen Sie Assert.Fail gegenüber immer falschen Bedingungen.
  • MSTEST0026 – Assertionsargumente sollten bedingten Zugriff vermeiden.
  • MSTEST0032 – Überprüfen Sie immer wahre Assertionsbedingungen.
  • MSTEST0037 – Verwenden Sie die richtigen Assert-Methoden.
  • MSTEST0038 – Vermeiden Sie die Verwendung von Werttypen.
  • MSTEST0039 – Verwenden Sie neuere Assert.Throws Methoden.
  • MSTEST0040 – Vermeiden Sie die Verwendung von Assertionen im asynchronen Void-Kontext.
  • MSTEST0046 - Nutzen Sie Assert anstelle von StringAssert.
  • MSTEST0051 - Assert.Throws sollte eine einzelne Anweisung enthalten.
  • MSTEST0053 – Formatparameter vermeiden Assert .
  • MSTEST0058 – Vermeiden Sie Assertions in Catch-Blocks.

Siehe auch

  • Last updated on