¿Cómo uso Assert para verificar que se haya lanzado una excepción?

¿Cómo uso Assert (u otra clase de prueba?) Para verificar que se haya lanzado una excepción.

Para “Visual Studio Team Test”, parece que aplica el atributo ExpectedException al método de la prueba.

Ejemplo de la documentación aquí: Un tutorial de prueba de unidad con Visual Studio Team Test

[TestMethod] [ExpectedException(typeof(ArgumentException), "A userId of null was inappropriately allowed.")] public void NullUserIdInConstructor() { LogonInfo logonInfo = new LogonInfo(null, "P@ss0word"); } 

Por lo general, su marco de prueba tendrá una respuesta para esto. Pero si no es lo suficientemente flexible, siempre puedes hacer esto:

 try { somethingThatShouldThrowAnException(); Assert.Fail(); // If it gets to this line, no exception was thrown } catch (GoodException) { } 

Como señala @Jonas, esto NO funciona para atrapar una excepción base:

 try { somethingThatShouldThrowAnException(); Assert.Fail(); // raises AssertionException } catch (Exception) { // Catches the assertion exception, and the test passes } 

Si absolutamente debe atrapar Exception, necesita volver a lanzar el Assert.Fail (). Pero en realidad, este es un signo de que no debes escribir esto a mano; verifique las opciones en su marco de prueba o vea si puede lanzar una excepción más significativa para probar.

 catch (AssertionException) { throw; } 

Debería ser capaz de adaptar este enfoque a lo que quiera, incluso especificar qué tipos de excepciones atrapar. Si solo espera ciertos tipos, termine los bloques de catch con:

 } catch (GoodException) { } catch (Exception) { // not the right kind of exception Assert.Fail(); } 

Mi método preferido para implementar esto es escribir un método llamado Throws, y usarlo como cualquier otro método de Assert. Desafortunadamente, .NET no le permite escribir un método de extensión estático, por lo que no puede usar este método como si realmente perteneciera a la construcción en la clase Assert; acaba de hacer otro llamado MyAssert o algo similar. La clase se ve así:

 using System; using Microsoft.VisualStudio.TestTools.UnitTesting; namespace YourProject.Tests { public static class MyAssert { public static void Throws( Action func ) where T : Exception { var exceptionThrown = false; try { func.Invoke(); } catch ( T ) { exceptionThrown = true; } if ( !exceptionThrown ) { throw new AssertFailedException( String.Format("An exception of type {0} was expected, but not thrown", typeof(T)) ); } } } } 

Eso significa que su prueba de unidad se ve así:

 [TestMethod()] public void ExceptionTest() { String testStr = null; MyAssert.Throws(() => testStr.ToUpper()); } 

Que se ve y se comporta mucho más como el rest de las syntax de prueba de su unidad.

Si está utilizando MSTest, que originalmente no tenía un atributo ExpectedException , podría hacer esto:

 try { SomeExceptionThrowingMethod() Assert.Fail("no exception thrown"); } catch (Exception ex) { Assert.IsTrue(ex is SpecificExceptionType); } 

si usa NUNIT, puede hacer algo como esto:

 Assert.Throws(() => methodToTest()); 

También es posible almacenar la excepción lanzada para validarla aún más:

 ExpectedException ex = Assert.Throws(() => methodToTest()); Assert.AreEqual( "Expected message text.", ex.Message ); Assert.AreEqual( 5, ex.SomeNumber); 

Ver: http://nunit.org/docs/2.5/exceptionAsserts.html

Tenga cuidado con el uso de ExpectedException, ya que puede dar lugar a varias trampas como se demuestra aquí:

http://geekswithblogs.net/sdorman/archive/2009/01/17/unit-testing-and-expected-exceptions.aspx

Y aquí:

http://xunit.github.io/docs/comparisons.html

Si necesita probar excepciones, hay maneras menos mal vistas. Puede usar el método try {act / fail} catch {assert}, que puede ser útil para frameworks que no tienen soporte directo para pruebas de excepción que no sean ExpectedException.

Una mejor alternativa es usar xUnit.NET, que es un marco de prueba de unidades muy moderno, prospectivo y extensible que ha aprendido de todos los demás errores y ha mejorado. Una de esas mejoras es Assert.Throws, que proporciona una syntax mucho mejor para hacer valer excepciones.

Puede encontrar xUnit.NET en github: http://xunit.github.io/

En un proyecto en el que estoy trabajando tenemos otra solución para hacer esto.

Primero, no me gusta el ExpectedExceptionAttribute porque toma en consideración qué llamada de método causó la excepción.

Lo hago con un método de ayuda en su lugar.

Prueba

 [TestMethod] public void AccountRepository_ThrowsExceptionIfFileisCorrupt() { var file = File.Create("Accounts.bin"); file.WriteByte(1); file.Close(); IAccountRepository repo = new FileAccountRepository(); TestHelpers.AssertThrows(()=>repo.GetAll()); } 

HelperMethod

 public static TException AssertThrows(Action action) where TException : Exception { try { action(); } catch (TException ex) { return ex; } Assert.Fail("Expected exception was not thrown"); return null; } 

Limpio, ¿no?)

Es un atributo en el método de prueba … no usa Assert. Se ve como esto:

 [ExpectedException(typeof(ExceptionType))] public void YourMethod_should_throw_exception() 

Puede descargar un paquete desde Nuget usando: PM> Install-Package MSTestExtensions que agrega la syntax Assert.Throws () en el estilo de nUnit / xUnit a MsTest.

Instrucciones de alto nivel: descargue el ensamblado y herede de BaseTest y puede usar la syntax Assert.Throws () .

El método principal para la implementación de Throws es el siguiente:

 public static void Throws(Action task, string expectedMessage, ExceptionMessageCompareOptions options) where T : Exception { try { task(); } catch (Exception ex) { AssertExceptionType(ex); AssertExceptionMessage(ex, expectedMessage, options); return; } if (typeof(T).Equals(new Exception().GetType())) { Assert.Fail("Expected exception but no exception was thrown."); } else { Assert.Fail(string.Format("Expected exception of type {0} but no exception was thrown.", typeof(T))); } } 

Divulgación: armé este paquete.

Más información: http://www.bradoncode.com/blog/2012/01/asserting-exceptions-in-mstest-with.html

MSTest ahora tiene una función Assert.ThrowsException que se puede usar así:

 Assert.ThrowsException(() => { Story actual = PersonalSite.Services.Content.ExtractHeader(String.Empty); }); 

No recomiendo usar el atributo ExpectedException (ya que es demasiado restrictivo y propenso a errores) o escribir un bloque try / catch en cada prueba (ya que es demasiado complicado y propenso a errores). Use un método de afirmación bien diseñado, ya sea proporcionado por su marco de prueba o escriba el suyo propio. Esto es lo que escribí y uso.

 public static class ExceptionAssert { private static T GetException(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(Action action) where T : Exception { Propagates(action, ""); } public static void Propagates(Action action, string message) where T : Exception { GetException(action, message); } public static void Propagates(Action action, Action validation) where T : Exception { Propagates(action, validation, ""); } public static void Propagates(Action action, Action validation, string message) where T : Exception { validation(GetException(action, message)); } } 

Ejemplos de usos:

  [TestMethod] public void Run_PropagatesWin32Exception_ForInvalidExeFile() { (test setup that might propagate Win32Exception) ExceptionAssert.Propagates( () => 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( () => CommandExecutionUtil.Run("NotThere.exe", new string[0]), e => StringAssert.Contains(e.Message, "NotThere.exe")); (more asserts or something) } 

NOTAS

Devolver la excepción en lugar de admitir una callback de validación es una idea razonable, excepto que hacerlo hace que la syntax de llamada de esta afirmación sea muy diferente de la que yo uso.

A diferencia de otros, utilizo ‘propagamentos’ en lugar de ‘lanzamientos’ ya que solo podemos probar si una excepción se propaga desde una llamada. No podemos probar directamente que se lanza una excepción. Pero supongo que podrías imaginar los lanzamientos para significar: arrojado y no atrapado.

PENSAMIENTO FINAL

Antes de pasar a este tipo de enfoque, consideré usar el atributo ExpectedException cuando una prueba solo verificaba el tipo de excepción y utilizaba un bloque try / catch si se requería más validación. Pero, no solo tendría que pensar en qué técnica utilizar para cada prueba, sino que cambiar el código de una técnica a otra según cambian las necesidades no fue un esfuerzo trivial. Usar un enfoque consistente ahorra esfuerzo mental.

Por lo tanto, en resumen, este enfoque deportivo: facilidad de uso, flexibilidad y solidez (es difícil hacerlo mal).

El asistente provisto por @Richiban funciona muy bien, excepto que no maneja la situación en la que se produce una excepción, pero no el tipo esperado. Las siguientes direcciones que:

 using System; using Microsoft.VisualStudio.TestTools.UnitTesting; namespace YourProject.Tests { public static class MyAssert { ///  /// Helper for Asserting that a function throws an exception of a particular type. ///  public static void Throws( Action func ) where T : Exception { Exception exceptionOther = null; var exceptionThrown = false; try { func.Invoke(); } catch ( T ) { exceptionThrown = true; } catch (Exception e) { exceptionOther = e; } if ( !exceptionThrown ) { if (exceptionOther != null) { throw new AssertFailedException( String.Format("An exception of type {0} was expected, but not thrown. Instead, an exception of type {1} was thrown.", typeof(T), exceptionOther.GetType()), exceptionOther ); } throw new AssertFailedException( String.Format("An exception of type {0} was expected, but no exception was thrown.", typeof(T)) ); } } } } 

Bueno, resumiré lo que todos los demás dijeron antes … De todos modos, aquí está el código que construí de acuerdo con las buenas respuestas 🙂 Todo lo que queda por hacer es copiar y usar …

 ///  /// Checks to make sure that the input delegate throws a exception of type TException. ///  /// The type of exception expected. /// The method to execute to generate the exception. public static void AssertRaises(Action methodToExecute) where TException : System.Exception { try { methodToExecute(); } catch (TException) { return; } catch (System.Exception ex) { Assert.Fail("Expected exception of type " + typeof(TException) + " but type of " + ex.GetType() + " was thrown instead."); } Assert.Fail("Expected exception of type " + typeof(TException) + " but no exception was thrown."); } 

Como mencionas el uso de otras clases de prueba, una mejor opción que el atributo ExpectedException es usar Shoudly ‘s Should.Throw .

 Should.Throw(() => { MyDivideMethod(1, 0); }); 

Digamos que tenemos un requisito de que el cliente debe tener una dirección para crear un pedido . De lo contrario, el método CreateOrderForCustomer debería dar como resultado una ArgumentException . Entonces podríamos escribir:

 [TestMethod] public void NullUserIdInConstructor() { var customer = new Customer(name := "Justin", address := null}; Should.Throw(() => { var order = CreateOrderForCustomer(customer) }); } 

Esto es mejor que usar un atributo ExpectedException porque estamos especificando qué debería arrojar el error. Esto hace que los requisitos en nuestras pruebas sean más claros y también facilita el diagnóstico cuando falla la prueba.

Tenga en cuenta que también hay un Should.ThrowAsync para pruebas de métodos asíncronos.

Consulte nUnit Docs para ver ejemplos sobre:

 [ExpectedException( typeof( ArgumentException ) )] 

Esto va a depender de qué marco de prueba estás usando?

En MbUnit, por ejemplo, puede especificar la excepción esperada con un atributo para asegurarse de obtener la excepción que realmente espera.

 [ExpectedException(typeof(ArgumentException))] 

Como alternativa, puede probar las excepciones de prueba que de hecho se lanzan con las 2 líneas siguientes en su prueba.

 var testDelegate = () => MyService.Method(params); Assert.Throws(testDelegate); 

En caso de utilizar NUnit , intente esto:

 Assert.That(() => { Your_Method_To_Test(); }, Throws.TypeOf().With.Message.EqualTo("Your_Specific_Message")); 

En las pruebas unitarias integradas de VS si simplemente quiere verificar que se lanza “cualquier excepción”, pero no conoce el tipo, puede usar un catch all:

 [TestMethod] [ExpectedException(typeof(Exception), AllowDerivedTypes = true)] public void ThrowExceptionTest() { //... } 

Aunque esta es una vieja pregunta, me gustaría agregar un nuevo pensamiento a la discusión. He extendido el patrón Organizar, Actuar, Reafirmar para ser esperado, Organizar, Actuar, Afirmar. Puede hacer un puntero de excepción esperado y luego afirmar que fue asignado a. Esto se siente más limpio que hacer tus Asserts en un bloque catch, dejando tu sección Act principalmente para que la única línea de código llame al método bajo prueba. Tampoco tiene que Assert.Fail(); o return de múltiples puntos en el código. Cualquier otra excepción producirá un error en la prueba, ya que no se detectará, y si se lanza una excepción de su tipo esperado, pero no fue la que estaba esperando, afirmando en contra del mensaje u otras propiedades de la excepción ayuda a asegurar que su prueba no pase inadvertidamente.

 [TestMethod] public void Bar_InvalidDependency_ThrowsInvalidOperationException() { // Expectations InvalidOperationException expectedException = null; string expectedExceptionMessage = "Bar did something invalid."; // Arrange IDependency dependency = DependencyMocks.Create(); Foo foo = new Foo(dependency); // Act try { foo.Bar(); } catch (InvalidOperationException ex) { expectedException = ex; } // Assert Assert.IsNotNull(expectedException); Assert.AreEqual(expectedExceptionMessage, expectedException.Message); }