2011-11-03 14 views
11

Normalmente uso Nunit pero en mi proyecto actual estoy usando MSTest. Ahora tengo una prueba que espera una excepción pero sigue fallando, y no tengo idea de por qué.MSTest ExpectedException falla

Aquí está un ejemplo sencillo que he utilizado para reproducir el problema:

[TestMethod, ExpectedException(typeof(ErrorResponseException))] 
     public void should_throw_exception() 
     { 
      throw new ErrorResponseException(); 
     } 

El ErrorResponseException es una clase que simplemente hereda de Exception, es decir, cualquiera sabe por qué está fallando, yo esperaría que pasar.

Respuesta

14

En NUnit, evitaría ExpectedException y usaré Assert.Throws (Exception Asserts) en su lugar. Te da un control más detallado. De lo contrario, la prueba pasará si alguna parte del método de prueba arroja esa excepción.

En MSTest, usted podría conseguir el mismo nivel de control con la construcción de la vieja escuela:

try 
{ 
    // code that you expect to throw goes here 
    Assert.Fail("Expected MyException"); 
} 
catch (MyException ex) 
{ 
    // optionally assert on the message - this can make tests fragile though 
} 

Con esto, no hay necesidad de que el atributo ExpectedException.

(El concepto proviene del desarrollo basado en pruebas libro: Una Guía Práctica de David Astels.)

+0

En mi escenario real es muy similar a lo que se dice para que te lo que pasa en el momento, sólo pareció extraño que no funciona dentro de MSTest. Continuará usando esta práctica en el futuro. – Grofit

+3

MSTest no es compatible con esto correctamente, es un error. ¡También es súper cojo! La solución anterior funcionará sin embargo –

3

Enchufe desvergonzado, pero me escribió un montaje simple que hace valer excepciones y mensajes de excepción de un poco más fácil y más legible en MSTest usando Assert.Throws() sintaxis. Escribí un blog post con todos los detalles.

3

Si está utilizando MSTest 10.0.1.0.0, ExpectedException parece no funcionar correctamente, use 10.0.0.0.0 en su lugar.

+1

Verdadero. Estoy enfrentando este problema ahora. – orange

2

Acabo de tener el mismo problema y encontré otra solución. Mi método para probar era async, pero olvidé la palabra clave await delante de la llamada en mi método de prueba.

La prueba:

[TestMethod] 
    [ExpectedException(typeof(InvalidOperationException))] 
    public async Task ShouldDoSomething(){ 
     // notice the missing await in the next line 
     this.testObject.DoSomethingAsync(); 
    } 

El Método de ensayo:

 public async Task<bool> DoSomethingAsync(){ 
      if(something) 
      { 
       throw new InvalidOperationException("Error while doing something"); 
      } 
      return false; 
     } 

Cuando me encontré con mi prueba de este tipo que falló. Pero tan pronto como cambie la prueba a lo siguiente:

[TestMethod] 
[ExpectedException(typeof(InvalidOperationException))] 
public async Task ShouldDoSomething(){ 
    await this.testObject.DoSomethingAsync(); 
} 

funcionó para mí.

0

El ExpectedExceptionAttribute se define ahora en varias DLL y el corrector de prueba de la unidad puede esperar ver el atributo de una DLL diferente a la que está utilizando su proyecto de prueba.

Como ejemplo, creé un proyecto de prueba de unidad en VS2017 y obtiene ExpectedException de Microsoft.VisualStudio.TestPlatform.TestFramework V14.0.0.0 - la prueba pasa en el IDE pero falla en TeamCity, incluso si usa el VSTest runner en la versión 2017.

Finalmente logré que pasara en TeamCity al eliminar todas las referencias a esta DLL en mis proyectos de prueba y reemplazarlos con la versión 10.0.0.0 de Mirosoft.VisualStudio.QualityTools.UnitTestFramework

1

En Visual Studio 15 con dependencias en MSTest.TestAdapter v1.1.18 y MSTest.TestFramework v1.1.18 también se podría utilizar

Assert.ThrowsException<ArgumentNullException>(() => MethodThatThrowsArgumentNullException());

Cuestiones relacionadas