Como verifico “nenhuma exceção ocorreu” em meu teste de unidade MSTest?

Estou escrevendo um teste de unidade para este método que retorna "void". Eu gostaria de ter um caso em que o teste seja aprovado quando não houver exceção lançada. Como faço para escrever isso em C #?

Assert.IsTrue(????)

(Meu palpite é que devo verificar, mas o que entra em "???")

Espero que minha pergunta esteja clara o suficiente.

Seu teste de unidade irá falhar de qualquer maneira se uma exceção for lançada - você não precisa colocar uma declaração especial.

Este é um dos poucos cenários onde você verá testes de unidade sem nenhuma asserção - o teste irá falhar implicitamente se uma exceção for levantada.

No entanto, se você realmente deseja escrever uma declaração para isso - talvez para ser capaz de capturar a exceção e relatar "não esperava nenhuma exceção, mas conseguiu isso ...", você pode fazer isso:

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

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

(o acima é um exemplo para NUnit, mas o mesmo vale para MSTest)

No NUnit, você pode usar:

Assert.DoesNotThrow(<expression>); 

para afirmar que seu código não lança uma exceção. Embora o teste falhe se uma exceção for lançada mesmo que não haja Assert em torno dela, o valor desta abordagem é que você pode distinguir entre expectativas não atendidas e bugs em seus testes, e você tem a opção de adicionar uma mensagem personalizada que será exibido em sua saída de teste. Uma saída de teste bem formulada pode ajudá-lo a localizar erros em seu código que causaram a falha de um teste.

Acho que é válido adicionar testes para garantir que seu código não está lançando exceções; por exemplo, imagine que você está validando a entrada e precisa converter uma string de entrada em uma longa. Pode haver ocasiões em que a string é nula, e isso é aceitável, portanto, você deseja garantir que a conversão da string não lance uma exceção. Haverá, portanto, um código para lidar com essa ocasião e, se você não escreveu um teste para isso, perderá a cobertura de uma importante parte da lógica.

Não teste se algo não acontece . É como garantir que o código não seja quebrado . Isso está meio que implícito, todos nós nos esforçamos por um código sem falhas e sem falhas. Você quer escrever testes para isso? Por que apenas um método? Você não quer que todos os seus métodos sejam testados para que não gerem exceções ? Seguindo esse caminho, você acabará com um teste extra, fictício e sem assertividade para cada método em sua base de código. Não traz nenhum valor.

Claro, se a sua exigência é para verificar método faz exceções captura , você faz teste que (ou revertê-la um pouco, teste que não jogue o que é suposto para pegar).

No entanto, a abordagem / práticas gerais permanecem intactas - você não escreve testes para alguns requisitos artificiais / vagos que estão fora do escopo do código testado (e testar se "funciona" ou "não joga" é geralmente um exemplo de (especialmente em cenários em que as responsabilidades do método são bem conhecidas).

Para simplificar - concentre-se no que seu código deve fazer e teste para isso.

Esta classe de auxiliar me arranhou com o MSTest. Talvez possa arranhar o seu também.

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

Gosto de ver um Assert.Whateverno final de cada teste, apenas para consistência ... sem um, posso realmente ter certeza de que não deveria haver um?

Para mim, isso é tão simples quanto colocar Assert.IsTrue(true);

Eu sei que eu não acidentalmente colocar esse código lá, e, portanto, eu deveria estar confiante o suficiente em um skim rápida através de que este era como pretendido.

    [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

    }

Meu amigo Tim me contou sobre ExpectedException . Eu realmente gosto deste b / c é mais sucinto, menos código e muito explícito que você está testando uma exceção.

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

Você pode ler muito mais sobre isso aqui: ExpectedException Attribute Usage .