Pregunta

Hemos estado utilizando NUnit y VisualStudio para escribir código C # .NET desde hace un tiempo. Excepciones Las pruebas se realizaron en el estilo de

antigua sintaxis:

[Test]
[ExpectException(typeof(ExceptionType))] 
public void TestExceptionType()
{

}

Ahora NUnit ha lanzado la versión 2.5.2 que introdujo Assert.Throws( Type expectedExceptionType, TestDelegate code ); Esto hace una excepción en la prueba de un conjunto mucho más flexible. Nuestras pruebas de excepción ahora el siguiente aspecto:

nueva sintaxis:

[Test]
public void TestWithNullBufferArgument()
{
   ArgumentNullException ex = Assert.Throws<ArgumentNullException>(() => _testInstance.TestFunction(null));

   // now you can examine the exception and it's properties
   Assert.AreEqual(ex.Message, "Argument was null");
}

Nuestro problema es que si Assert.Throws se utiliza Visual Studio toser una ventana que muestra una excepción no controlada cuando NUnit (ya sea consola o corredor GUI) se utiliza para depurar el programa.

para aclarar esto: hemos establecido el proyecto VS que contiene las pruebas unitarias para funcionar nunit-x86.exe al depurar. (Ver las propiedades del proyecto, ficha de depuración, iniciar la acción está configurado para ejecutarse nunit-x86.exe)

Esto detiene NUnit de continuar las pruebas. Es posible continuar con las pruebas de depuración / unidad presionando F5 pero esto no es una solución viable.

¿Hay alguna manera de evitar esto? Poner un bloque try ... catch alrededor de las Assert.Throws no hace nada ya que la excepción ocurre en el código delegado.

Espero que alguien pueda arrojar algo de luz sobre esto.

¿Fue útil?

Solución

Aparece el problema en sí, porque lo más probable es que la opción Habilitar Sólo mi código activada (Herramientas-> Opciones-> Debugging-> General-> Habilitar Sólo mi código).

"Cuando se activa esta función, el depurador muestra y pasos en el código de usuario (" Mi Código ") solamente, haciendo caso omiso de código del sistema y otro código que está optimizado o no tiene símbolos de depuración" (véase " general, depuración, el cuadro de diálogo Opciones de ")

Normalmente usted tiene una versión comercial de nunit.framework.dll que no tiene un archivo nunit.framework.pdb correspondiente.

Así que hay 2 opciones:

  1. Desactivar "Sólo mi código" característica

  2. Descarga de fuentes nunit (desde http://www.nunit.org /index.php?p=download ), construirlos en modo de depuración, puso todo nunit.framework. * (DLL, PDB, XML) en otro directorio lib o en su solución y de referencia que nunit.framework.dll en su proyecto de prueba.

Espero que esto ayude.

Otros consejos

El mismo problema también me molestaba desde hace bastante tiempo, hice algunas pruebas y se encontró lo siguiente:

Si una biblioteca (nunit en este caso) se compila con información de depuración se pone a 'ninguno', entonces si constructo similar al que aparece a continuación se ejecuta en el canto de la biblioteca y el código del delegado se produce una excepción, entonces VS deja de quejarse de excepción no manejada por el código de usuario.

Biblioteca de código:

public static Exception Throws(TestDelegate code, string message)
{
    Exception caughtException = null;

    try
    {
        code();
    }
    catch (Exception ex)
    {
        caughtException = ex;
    }        

    return caughtException;
}

El código de cliente:

private void btnTest_Click(object sender, EventArgs e)
{
  var ex = MyAssert.Throws(() => { throw new Exception(); }, "");    
}

Configuración de la información de depuración de un proyecto de biblioteca a cualquier otra opción que no sea 'ninguna' se resuelve el problema, es decir depurador no se detiene más en estas excepciones no controladas "kinda". Lo he comprobado con nunit y mi propia biblioteca enrollado a mano con el código anterior (tomó un fragmento de nunit los tiros de método). Supongo que es una característica o una "característica" de VS.

Esto nos deja con no tantas opciones:

  1. Filtro excepción sugirió anteriormente

  2. Recompile nunit.framework.dll para uso local, para evitar esas paradas molestos

Otras opciones podrían ser ponerse en contacto con cualquiera de los equipos ms o NUnit o ambos y pedirles que investigar / aclarar tema y compilar NUnit con nivel mínimo de información de depuración respectevily.

Editar:

Encontrados una opción más.

  1. En mi caso desmarcando 'Suprimir optimización JIT en la carga del módulo también hace el truco, aunque las bibliotecas compiladas sin información de depuración. Sin embargo, sólo funciona cuando el proyecto se ejecuta en la configuración de liberación.

Creo que se le está cegado por la afirmación de NUnit. Se podría lograr lo mismo con un try sencilla / catch.

try
{
  _testInstance.TestFunction(null);
  Assert.Fail("The method should have thrown...");
}catch{}

Ahora, usted tiene todo lo necesario. Usted no la excepción si no se lanza y su código normal puede manejar excepciones como se esperaba.

Podría ser alcanzable mediante la desactivación de la excepción. Excepciones menú Depurar abierta /, y la búsqueda de su excepción.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top