Comment vérifier «aucune exception ne s'est produite» dans mon test unitaire MSTest?

J'écris un test unitaire pour cette méthode qui renvoie "void". Je voudrais avoir un cas où le test réussit lorsqu'il n'y a pas d'exception levée. Comment écrire cela en C #?

Assert.IsTrue(????)

(Je suppose que c'est ainsi que je devrais vérifier, mais qu'est-ce qui se passe dans "???")

J'espère que ma question est suffisamment claire.

Votre test unitaire échouera de toute façon si une exception est levée - vous n'avez pas besoin de mettre une assertion spéciale.

C'est l'un des rares scénarios où vous verrez des tests unitaires sans aucune assertion - le test échouera implicitement si une exception est déclenchée.

Cependant, si vous voulez vraiment écrire une assertion pour ceci - peut-être pour pouvoir attraper l'exception et signaler "n'attend pas d'exception mais a obtenu ceci ...", vous pouvez le faire:

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

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

(ce qui précède est un exemple pour NUnit, mais il en va de même pour MSTest)

Dans NUnit, vous pouvez utiliser:

Assert.DoesNotThrow(<expression>); 

pour affirmer que votre code ne lève pas d'exception. Bien que le test échoue si une exception est levée même s'il n'y avait pas d'assert autour d'elle, la valeur de cette approche est que vous pouvez alors faire la distinction entre les attentes non satisfaites et les bogues dans vos tests, et vous avez la possibilité d'ajouter un message personnalisé qui sera affiché dans votre sortie de test. Une sortie de test bien formulée peut vous aider à localiser les erreurs dans votre code qui ont provoqué l'échec d'un test.

Je pense qu'il est valable d'ajouter des tests pour s'assurer que votre code ne lève pas d'exceptions; par exemple, imaginez que vous validez une entrée et que vous devez convertir une chaîne entrante en un long. Il peut arriver que la chaîne soit nulle, ce qui est acceptable, vous voulez donc vous assurer que la conversion de chaîne ne lève pas d'exception. Il y aura donc du code pour gérer cette occasion, et si vous n'avez pas écrit de test pour cela, vous manquerez de couverture autour d'un élément de logique important.

Ne testez pas que quelque chose n'arrive pas . C'est comme s'assurer que le code ne casse pas . C'est en quelque sorte implicite, nous nous efforçons tous de trouver du code sans rupture et sans bogue. Tu veux faire des tests pour ça? Pourquoi une seule méthode? Ne voulez-vous pas que toutes vos méthodes soient testées sans faire exception ? En suivant cette route, vous vous retrouverez avec un test supplémentaire, factice et sans affirmation pour chaque méthode de votre base de code. Cela n'apporte aucune valeur.

Bien sûr, si votre exigence est de vérifier la méthode fait des exceptions de capture , vous faites test (ou renverser un peu, test qui ne jette pas ce qu'il est censé attraper).

Cependant, l'approche / les pratiques générales restent intactes - vous n'écrivez pas de tests pour certaines exigences artificielles / vagues qui sont hors de portée du code testé (et tester que "ça marche" ou "ne lance pas" est généralement un exemple de tel - en particulier dans un scénario où les responsabilités de la méthode sont bien connues).

Pour faire simple, concentrez-vous sur ce que votre code doit faire et testez-le.

Cette classe d'aide a gratté ma démangeaison avec MSTest. Peut-être que cela peut aussi rayer le vôtre.

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

J'aime voir un Assert.Whateverà la fin de chaque test, juste pour la cohérence ... sans un, puis-je vraiment être sûr qu'il n'y en a pas?

Pour moi, c'est aussi simple que de mettre Assert.IsTrue(true);

Je sais que je n'ai pas accidentellement mis ce code là-dedans, et donc je devrais être suffisamment confiant en un rapide survol que c'était comme prévu.

    [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

    }

Mon ami Tim m'a parlé de ExpectedException . J'aime vraiment ça car c'est plus succinct, moins de code et très explicite que vous testez une exception.

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

Vous pouvez en savoir plus ici: Utilisation d'attributs ExpectedException .