Wie überprüfe ich in meinem MSTest-Komponententest, dass keine Ausnahme aufgetreten ist?

Ich schreibe einen Unit-Test für diese eine Methode, der "void" zurückgibt. Ich hätte gerne einen Fall, in dem der Test bestanden wird, wenn keine Ausnahme ausgelöst wird. Wie schreibe ich das in C #?

Assert.IsTrue(????)

(Ich vermute, so sollte ich das überprüfen, aber was geht in "???")

Ich hoffe meine Frage ist klar genug.

Ihr Komponententest schlägt ohnehin fehl, wenn eine Ausnahme ausgelöst wird - Sie müssen keine spezielle Zusicherung abgeben.

Dies ist eines der wenigen Szenarien, in denen Unit-Tests ohne Zusicherungen angezeigt werden. Der Test schlägt implizit fehl, wenn eine Ausnahme ausgelöst wird.

Wenn Sie jedoch wirklich eine Behauptung dazu schreiben wollten - vielleicht um die Ausnahme abzufangen und "keine Ausnahme erwartet, aber erhalten ..." zu melden, können Sie dies tun:

[Test]
public void TestNoExceptionIsThrownByMethodUnderTest()
{
    var myObject = new MyObject();

    try
    {
        myObject.MethodUnderTest();
    }
    catch (Exception ex)
    {
        Assert.Fail("Expected no exception, but got: " + ex.Message);
    }
}

(Das Obige ist ein Beispiel für NUnit, aber das Gleiche gilt für MSTest.)

In NUnit können Sie Folgendes verwenden:

Assert.DoesNotThrow(<expression>); 

um zu behaupten, dass Ihr Code keine Ausnahme auslöst. Obwohl der Test fehlschlagen würde, wenn eine Ausnahme ausgelöst würde, selbst wenn keine Bestätigung vorhanden wäre, besteht der Wert dieses Ansatzes darin, dass Sie in Ihren Tests zwischen nicht erfüllten Erwartungen und Fehlern unterscheiden können und die Option haben, eine benutzerdefinierte Nachricht hinzuzufügen wird in Ihrer Testausgabe angezeigt. Eine gut formulierte Testausgabe kann Ihnen helfen, Fehler in Ihrem Code zu finden, die dazu geführt haben, dass ein Test fehlgeschlagen ist.

Ich denke, es ist gültig, Tests hinzuzufügen, um sicherzustellen, dass Ihr Code keine Ausnahmen auslöst. Stellen Sie sich beispielsweise vor, Sie validieren die Eingabe und müssen eine eingehende Zeichenfolge in eine lange konvertieren. Es kann vorkommen, dass die Zeichenfolge null ist. Dies ist akzeptabel. Sie möchten daher sicherstellen, dass bei der Zeichenfolgenkonvertierung keine Ausnahme ausgelöst wird. Es wird daher Code geben, der diese Gelegenheit behandelt, und wenn Sie keinen Test dafür geschrieben haben, fehlt Ihnen die Abdeckung eines wichtigen logischen Teils.

Testen Sie nicht, dass etwas nicht passiert . Es ist so, als würde man sicherstellen, dass der Code nicht kaputt geht . Das ist irgendwie impliziert, wir alle streben nach nicht brechendem, fehlerfreiem Code. Sie möchten Tests dafür schreiben? Warum nur eine Methode? Wollen Sie nicht, dass alle Ihre Methoden getestet werden, damit sie keine Ausnahme auslösen ? Wenn Sie dieser Straße folgen, erhalten Sie für jede Methode in Ihrer Codebasis einen zusätzlichen Dummy-Test ohne Assert. Es bringt keinen Wert.

Natürlich, wenn Ihre Anforderung Methode , um zu überprüfen ist tut Ausnahmen fangen , sind Sie testen , ob (oder es etwas rückgängig zu machen ; Test , dass es nicht das, was wirft es zu fangen soll).

Der allgemeine Ansatz / die allgemeinen Praktiken bleiben jedoch erhalten - Sie schreiben keine Tests für einige künstliche / vage Anforderungen, die außerhalb des Bereichs des getesteten Codes liegen (und das Testen, dass "es funktioniert" oder "nicht wirft", ist normalerweise ein Beispiel dafür solche - insbesondere in Szenarien, in denen die Verantwortlichkeiten der Methode bekannt sind).

Um es einfach auszudrücken: Konzentrieren Sie sich darauf, was Ihr Code zu tun hat, und testen Sie dies.

Diese Helferklasse kratzte mich mit MSTest am Juckreiz. Vielleicht kann es auch deine kratzen.

[TestMethod]
public void ScheduleItsIneligibilityJob_HasValid_CronSchedule()
{
    // Arrange
    var factory = new StdSchedulerFactory();
    IScheduler scheduler = factory.GetScheduler();

    // Assert
    AssertEx.NoExceptionThrown<FormatException>(() =>
        // Act
        _service.ScheduleJob(scheduler)
    );
}

public sealed class AssertEx
{
    public static void NoExceptionThrown<T>(Action a) where T:Exception
    {
        try
        {
            a();
        }
        catch (T)
        {
            Assert.Fail("Expected no {0} to be thrown", typeof(T).Name);
        }
    }
}

Ich mag es, Assert.Whateveram Ende jedes Tests eine zu sehen, nur aus Gründen der Konsistenz ... kann ich ohne eine wirklich sicher sein, dass es dort keine geben soll?

Für mich ist das so einfach wie Putten Assert.IsTrue(true);

Ich weiß, dass ich diesen Code nicht versehentlich dort eingefügt habe, und daher sollte ich sicher genug sein, schnell durchzublättern, dass dies wie beabsichtigt war.

    [TestMethod]
    public void ProjectRejectsGappedVersioningByDefault() {

        var files = new List<ScriptFile>();
        files.Add(ScriptProjectTestMocks.GetVersion1to2());
        files.Add(ScriptProjectTestMocks.GetVersion3to4());

        Assert.Throws<ScriptProject.InvalidProjectFormatException>(() => {
            var sut = new ScriptProject(files);
        });

    }

    [TestMethod]
    public void ProjectAcceptsGappedVersionsExplicitly() {

        var files = new List<ScriptFile>();
        files.Add(ScriptProjectTestMocks.GetVersion1to2());
        files.Add(ScriptProjectTestMocks.GetVersion3to4());

        var sut = new ScriptProject(files, true);

        Assert.IsTrue(true);   // Assert.Pass() would be nicer... build it in if you like

    }

Mein Freund Tim erzählte mir von ExpectedException . Ich mag dieses B / C wirklich, es ist prägnanter, weniger Code und sehr explizit, dass Sie auf eine Ausnahme testen.

[TestMethod()]
[ExpectedException(typeof(System.Exception))]
public void DivideTest()
{
    int numerator = 4;
    int denominator = 0;
    int actual = numerator / denominator;
}

Weitere Informationen hierzu finden Sie hier: Verwendung der ExpectedException-Attribute .