Cómo diagnosticar "Error de TestFixtureSetUp"

Question

Usamos TeamCity como nuestro servidor de CI, y acabo de comenzar a ver "TestFixtureSetUp Failed" en la ventana de falla de prueba.

¿Alguna idea de cómo voy a depurar este problema? Las pruebas funcionan bien en mi estación de trabajo (corredor de prueba R # en VS2008).

Answer 1

Es un error en la implementación de TestFixtureSetUp (y TestFixtureTearDown) que las excepciones no estén bien informadas. Escribí la primera implementación de ellos y nunca lo hice funcionar de la manera que se suponía. En ese momento, los conceptos del código NUnit estaban estrechamente relacionados con la idea de que las acciones estaban directamente relacionadas con una prueba única. Entonces, el informe de todo estaba relacionado con un resultado de prueba. No había realmente un espacio para informar algo que sucedió en el nivel de suite sin una gran re-escritura (no es una refactorización cuando cambias una oveja a una escalera mecánica).

Debido a ese poco de historia, es difícil averiguar qué sucedió realmente en TestFixtureSetUp. No hay un buen lugar para adjuntar el error. La llamada TestFixtureSetUp es un efecto secundario de ejecutar una prueba en lugar de estar directamente relacionado con ella.

@TrueWill tiene la idea correcta. Verifique los registros y luego modifique la prueba para agregar más registros si es necesario. Es posible que desee poner try/catch dentro de TestFixtureSetup y registrar mucho en el bloque catch. Solo pensé que podría agregarle algunos antecedentes (en otras palabras, es mi culpa).

Answer 2

Verificaría primero el registro de compilación.

Si no es obvio, podría intentar incluir Console.WriteLines en las pruebas. No estoy seguro, pero creo que están escritos en el Build Log. De forma alternativa, puede iniciar sesión en un archivo (incluso usando log4net si desea hacerse elegante).

Si tiene Visual Studio instalado en el servidor de CI, puede intentar ejecutar las compilaciones/pruebas desde allí. Si se trata de un problema de conectividad, eso podría resolverlo.

He visto problemas de ruta, sin embargo, donde las rutas relativas a los archivos ya no eran correctas o se usaban rutas absolutas. Estos son más difíciles de depurar, y pueden requerir el registro de las rutas y luego verificar si existen en el servidor de compilación.

Answer 3

Tuve este problema y fue causado por la adición de un solo de lectura privada Dictionary en la clase, de la misma manera que se agrega un private const string.

He intentado hacer que el Dictionary sea constante pero no se puede hacer eso en tiempo de compilación. Lo resolví poniendo mi Dictionary en un método que lo devuelve.

Answer 4

Recibí el mismo error al ejecutar cualquier prueba con SpecFlow usando Visual NUnit. Cuando intenté hacer lo mismo desde el Unit Test Explorer (proporcionado por Resharper), me dio un mensaje más útil: Los métodos de enlace con más de 10 parámetros no son compatibles. Me di cuenta de que no puedo tener un método SpecFlow con más de 10 parámetros, tuve que eliminar la prueba.

Answer 5

Pude ver que no estaba creando correctamente mi base de datos de prueba al hacer un cambio rápido a la Prueba de Unidad VS. En mi caso, fue capaz de devolver una mejor respuesta a la razón por la cual falló. Usualmente uso NUnit. "No se ha podido crear la instancia de la clase X. Error: System.Data.SqlClient.SqlException: se ha producido un error de activación de archivo. El nombre físico del archivo '\ DbTest.mdf' puede ser incorrecto. Diagnostique y corrija errores adicionales, y vuelva a intentar la operación CREATE DATABASE failed. Algunos nombres de archivo enumerados no se pudieron crear. Verifique los errores relacionados. "

Answer 6

tenía este síntoma causado por un error durante la inicialización del campo. Si su inicializar sus campos en el método [SetUp], debería ver un mensaje de error mejor.

[TestFixture] 
internal class CommandParserTest 
{ 
    // obscure error message 
    private CommandParser parser = new CommandParser(...); 
    ... 
} 

[TestFixture] 
internal class CommandParserTest 
{ 
    private CommandParser parser; 

    [SetUp] 
    public void BeforeTest() 
    { 
     // better error message 
     parser = new CommandParser(...); 
    } 
    ... 
} 

Answer 7

que estaba preocupado por esto hoy. Hice lo siguiente para obtener el error real.

(1) Escriba otra prueba en un dispositivo separado que inicialice una instancia del accesorio de prueba problemático, explícitamente llama a los métodos de instalación como TestFixtureSetUp y SetUp, y luego ejecuta el método de prueba objetivo

(2) Agregue el código de manejo de excepciones para el nuevo código anterior, y registre/envíe la excepción real a alguna parte.

Answer 8

Me encontré con esto hoy al crear algunas pruebas de integración que tienen una configuración de ejecución prolongada que no quiero duplicar. Terminé envolviendo toda la lógica de configuración de la instalación de prueba en un try/catch. A continuación, agrego un método SetUp cuyo único propósito es ver si se produjo una falla durante la configuración del dispositivo y proporcionar un mejor registro.

Exception testFixtureSetupException = null; 

[TestFixtureSetUp] 
public void FixtureSetup() 
{ 
    try 
    { 
     // DoTestFixtureSetup 
    } 
    catch (Exception ex) 
    { 
     testFixtureSetupException = ex; 
    } 
} 

[SetUp] 
// NUnit doesn't support very useful logging of failures from a TestFixtureSetUp method. We'll do the logging here. 
public void CheckForTestFixturefailure() 
{   
    if (testFixtureSetupException != null) 
    { 
     string msg = string.Format("There was a failure during test fixture setup, resulting in a {1} exception. You should check the state of the storage accounts in Azure before re-running the RenewStorageAccountE2ETests. {0}Exception Message: {3}{0}Stack Trace:{4}", 
      Environment.NewLine, testFixtureSetupException.GetType(), accountNamePrefix, testFixtureSetupException.Message, testFixtureSetupException.StackTrace); 
     Assert.Fail(msg); 
    } 
} 

Answer 9

ejecutar la prueba de unidad en el modo de depuración . Puede encontrar un error de tiempo de ejecución en la configuración.

Answer 10

En caso de que puede ayudar a alguien: Puede detectar la excepción y escribir en la consola en el TearDown

Algo así como:

[SetUpFixture] 
public class BaseTest 
{ 
    private Exception caughtException = null; 

    [SetUp] 
    public void RunBeforeAnyTests() 
    { 
     try 
     { 
      throw new Exception("On purpose"); 
     } 
     catch (Exception ex) 
     { 
      caughtException = ex;    
     } 
    } 

    [TearDown] 
    public void RunAfterAnyTests() 
    { 
     if (caughtException != null) 
     { 
      Console.WriteLine(string.Format("TestFixtureSetUp failed in {0} - {1}", this.GetType(), caughtException.Message)); 
     }   
    } 

} 

Y el resultado será:

TestFixtureSetUp falló en IntegratedTests.Services.BaseTest - A propósito

Answer 11

Si está utilizando SpecFlow y C# en Visual Studio, mire en el archivo generado automáticamente <whatever>.feature.cs después de que la prueba falla. En la línea public partial class <whatever>Feature, debería ver un símbolo que al pasar el cursor sobre la pantalla mostrará el motivo por el que falló la configuración del dispositivo NUnit. En mi caso, fue que algunos de mis métodos BeforeFeature en mi clase TestHooks no eran estáticos. Todos los métodos BeforeTestRun, AfterTestRun, BeforeFeature y AfterFeature deben ser estáticos.