Não recomendo usar o atributo ExpectedException (já que é muito restritivo e propenso a erros) ou escrever um bloco try / catch em cada teste (já que é muito complicado e propenso a erros). Use um método de afirmação bem projetado - fornecido pela sua estrutura de teste ou escreva seu próprio. Aqui está o que eu escrevi e uso.
public static class ExceptionAssert
{
private static T GetException<T>(Action action, string message="") where T : Exception
{
try
{
action();
}
catch (T exception)
{
return exception;
}
throw new AssertFailedException("Expected exception " + typeof(T).FullName + ", but none was propagated. " + message);
}
public static void Propagates<T>(Action action) where T : Exception
{
Propagates<T>(action, "");
}
public static void Propagates<T>(Action action, string message) where T : Exception
{
GetException<T>(action, message);
}
public static void Propagates<T>(Action action, Action<T> validation) where T : Exception
{
Propagates(action, validation, "");
}
public static void Propagates<T>(Action action, Action<T> validation, string message) where T : Exception
{
validation(GetException<T>(action, message));
}
}
Exemplo usa:
[TestMethod]
public void Run_PropagatesWin32Exception_ForInvalidExeFile()
{
(test setup that might propagate Win32Exception)
ExceptionAssert.Propagates<Win32Exception>(
() => CommandExecutionUtil.Run(Assembly.GetExecutingAssembly().Location, new string[0]));
(more asserts or something)
}
[TestMethod]
public void Run_PropagatesFileNotFoundException_ForExecutableNotFound()
{
(test setup that might propagate FileNotFoundException)
ExceptionAssert.Propagates<FileNotFoundException>(
() => CommandExecutionUtil.Run("NotThere.exe", new string[0]),
e => StringAssert.Contains(e.Message, "NotThere.exe"));
(more asserts or something)
}
NOTAS
Retornar a exceção em vez de oferecer suporte a um retorno de chamada de validação é uma idéia razoável, exceto que isso torna a sintaxe de chamada dessa declaração muito diferente das outras que eu uso.
Diferentemente de outros, eu uso 'propaga' em vez de 'lança', pois só podemos testar se uma exceção se propaga a partir de uma chamada. Não podemos testar diretamente se uma exceção é lançada. Mas suponho que você possa imaginar lances como significados: jogados e não capturados.
PENSAMENTO FINAL
Antes de mudar para esse tipo de abordagem, considerei usar o atributo ExpectedException quando um teste verificou apenas o tipo de exceção e usar um bloco try / catch se mais validação fosse necessária. Mas não apenas precisaria pensar em qual técnica usar para cada teste, mas alterar o código de uma técnica para outra conforme as necessidades mudassem não era um esforço trivial. Usar uma abordagem consistente economiza esforço mental.
Então, em resumo, essa abordagem é esportiva: facilidade de uso, flexibilidade e robustez (difícil de fazer errado).