Come faccio a controllare "non si è verificata alcuna eccezione" nel mio unit test MSTest?

Sto scrivendo uno unit test per questo metodo che restituisce "void". Vorrei avere un caso in cui il test viene superato quando non vengono generate eccezioni. Come lo scrivo in C #?

Assert.IsTrue(????)

(La mia ipotesi è che questo sia il modo in cui dovrei controllare, ma cosa c'è in "???")

Spero che la mia domanda sia abbastanza chiara.

Il tuo unit test fallirà comunque se viene generata un'eccezione: non è necessario inserire un'asserzione speciale.

Questo è uno dei pochi scenari in cui vedrai unit test senza alcuna asserzione: il test fallirà implicitamente se viene sollevata un'eccezione.

Tuttavia, se vuoi davvero scrivere un'asserzione per questo, forse per essere in grado di catturare l'eccezione e segnalare "non aspettavo eccezioni ma ho ottenuto questo ...", puoi farlo:

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

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

(quanto sopra è un esempio per NUnit, ma lo stesso vale per MSTest)

In NUnit puoi usare:

Assert.DoesNotThrow(<expression>); 

per affermare che il codice non genera un'eccezione. Anche se il test fallirebbe se viene lanciata un'eccezione anche se non ci fosse Assert attorno ad essa, il valore di questo approccio è che puoi quindi distinguere tra aspettative non soddisfatte e bug nei tuoi test e hai la possibilità di aggiungere un messaggio personalizzato verrà visualizzato nell'output di prova. Un output di test ben formulato può aiutarti a individuare gli errori nel codice che hanno causato il fallimento di un test.

Penso che sia valido aggiungere test per garantire che il codice non generi eccezioni; ad esempio, immagina di convalidare l'input e di dover convertire una stringa in entrata in una stringa lunga. Ci possono essere occasioni in cui la stringa è nulla, e questo è accettabile, quindi vuoi assicurarti che la conversione della stringa non generi un'eccezione. Ci sarà quindi del codice per gestire questa occasione, e se non hai scritto un test per questo ti mancherà la copertura di un importante pezzo di logica.

Non verificare che qualcosa non accada . È come assicurarsi che il codice non si rompa . Questo è un po 'implicito, tutti ci sforziamo per un codice senza interruzioni e senza bug. Vuoi scrivere test per questo? Perché un solo metodo? Non vuoi che tutti i tuoi metodi vengano testati in modo da non generare eccezioni ? Seguendo questa strada, ti ritroverai con un test in più, fittizio e senza asserzioni per ogni metodo nella tua base di codice. Non porta valore.

Naturalmente, se la vostra esigenza è quella di verificare il metodo fa eccezioni di cattura , fate test che (o invertire un po ', prova che esso non buttare ciò che si suppone di cattura).

Tuttavia, l'approccio / le pratiche generali rimangono intatti: non si scrivono test per alcuni requisiti artificiali / vaghi che non rientrano nell'ambito del codice testato (e il test che "funziona" o "non genera" è di solito un esempio di tale - specialmente nello scenario in cui le responsabilità del metodo sono ben note).

Per semplificare, concentrati su ciò che il tuo codice deve fare e prova per questo.

Questa classe di aiutanti ha graffiato il mio prurito con MSTest. Forse può graffiare anche il tuo.

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

Mi piace vedere un Assert.Whateveralla fine di ogni test, solo per coerenza ... senza uno, posso davvero essere sicuro che non dovrebbe essercene uno lì?

Per me, questo è semplice come mettere Assert.IsTrue(true);

Io so che non ho accidentalmente messo quel codice in là, e quindi dovrei essere abbastanza sicuri in uno scremato veloce attraverso che questo era come previsto.

    [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

    }

Il mio amico Tim mi ha parlato di ExpectedException . Mi piace molto questo b / c, è più succinto, meno codice e molto esplicito che stai testando un'eccezione.

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

Puoi leggere di più a riguardo qui: ExpectedException Attribute Usage .