6

Esto es extraño, pero de repente el ExpectedExceptionAttribute dejó de funcionar el otro día. No estoy seguro de lo que salió mal. Estoy ejecutando VS 2010 y VS 2005 uno al lado del otro. No funciona en VS 2010. Esta prueba debe aprobarse, sin embargo está fallando:ExpectedExceptionAttribute no funciona en MSTest

[TestMethod] 
[ExpectedException(typeof(ArgumentNullException))] 
public void Test_Exception() 
{ 
    throw new ArgumentNullException("test"); 
} 

¿Alguna idea? Esto realmente es sux.

+0

Me sale lo mismo, pero no puedo encontrar nada al respecto. Alguien más tiene el mismo problema. http://stackoverflow.com/questions/2628965/expectedexception-on-testmethod-visual-studio-2010 –

+0

¿Está depurando o ejecutando la prueba? – Joop

Respuesta

1

He tenido el mismo problema, pero finalmente logré ponerlo en funcionamiento. No estoy muy seguro de cómo, pero aquí hay una lista de cosas que hice entre que no funcionaba cuando comenzó a funcionar de nuevo.

  • convertido el proyecto que está siendo probado para .NET 4
  • Se apaga cobertura de código
  • Convertido cobertura de código de vuelta de nuevo
  • realizó un RebuildAll en el proyecto de prueba

No está seguro de qué bit fijado sin embargo. De todos modos, espero que esto ayude!

12

No resucitar un hilo muerto, pero me encontré con esto cuando esto me sucedió repentinamente, en caso de que pueda ayudar a otros. Finalmente encontré cuál era el problema, que puede correlacionarse con lo que Jon encontró. El atributo ExpectedException parece funcionar solo si el proyecto se reconoce como TestProject. (No es sólo un ensamblado de .NET)

de descarga del proyecto, editar el archivo csproj y compruebe que el siguiente ajuste está ahí:

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids> 

(Suponiendo proyectos VS2010) cargar el proyecto y reconstruir. Las pruebas de ExpectedException ahora deberían pasar.

Nos encontramos con este problema cuando la estandarización de las pruebas de NUnit a MSTest (Gracias TFS Build CI) y encontraron que después de la sustitución Assert.Throws <> hermosa simplicidad & flexibilidad con [ExpectedException (Tipo)] basura, (por no mencionar Perdiendo [TestCase()]!) las pruebas ExpectedException fallaron sin razón. Cambia de nuevo a NUnit con ExpectedException, no hay problema, MSTest se niega a ejecutarlo.

hace falta decir que estará empujando para obtener NUnit atrás, después de encontrar: http://blog.shawnewallace.com/2011/02/running-nunit-tests-in-tfs-2010.html

+1

¡Hola Steve! No hay vergüenza en responder a viejas preguntas, particularmente con una respuesta tan buena. ¡Gracias! – tmesser

+0

Uso realmente el constructo Nunit (Assert.throws) desde dentro de MsTest ;-) – Konstantin

+0

También me ha funcionado en VS2012. Pero es aún más extraño: tengo muchas bibliotecas de clases simples con esta ExpectedException que funcionan como un encanto. Incluso el proyecto ofensivo una vez funcionó y de repente dejó de funcionar. – JotaBe

1

Este hilo apareció en una búsqueda en Google y ya que me encontré con esto hoy también, pero por una razón diferente, me quedo agregue otro anser posible aquí.

Tenía pruebas unitarias para alguna función con el atributo [ExpectedException] en su lugar, pero una actualización reciente del código hizo que la función probada async mejorara el rendimiento.

Esto provocó que fallaran estas pruebas unitarias. La solución más sencilla era también hacer la prueba de la unidad asíncrono, volver tareas y esperar la función de llamada:

[TestMethod] 
[ExpectedException(typeof(Exception))] 
public async Task UnitTestAnAsyncFunction() 
{ 
    await sut.DoStuffAsync(); 

    //Assert 
    //ExpectedException 
} 
0

tengo otra respuesta, que no tiene necesidad de editar el archivo csproj. Parece que la causa raíz era solo una referencia faltante. Agregué Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll a las referencias del proyecto y using Microsoft.VisualStudio.TestTools.UnitTesting; a los archivos de código.El DLL puede encontrarse en

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\ 

o

C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\ 

Espero que pueda ayudar a cualquier persona a ahorrar algo de tiempo.