Cómo diagnosticar "TestFixtureSetUp Failed"

Question

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

¿Alguna idea de cómo hago para solucionar este problema? Las pruebas se ejecutan bien en mi estación de trabajo (R # test runner en VS2008).

Answer 1

Es un poco un defecto en la implementación de TestFixtureSetUp (y TestFixtureTearDown) que las excepciones no se informan bien. Escribí la primera implementación de ellos y nunca conseguí que funcionara como se suponía. En el momento en que los conceptos en el código NUnit estaban estrechamente relacionados con la idea de que las acciones estaban directamente relacionadas con una sola prueba. Así que el reporte de todo estaba relacionado con un resultado de prueba. Realmente no había un espacio para informar sobre algo que sucedió a nivel de suite sin una gran reescritura (no es una refactorización cuando cambias una oveja por una escalera mecánica).

Debido a ese poco de historia, es difícil descubrir qué sucedió realmente en un 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 en try / catch dentro de TestFixtureSetup y registrar mucho en el bloque catch. Simplemente pensé que podría agregarle algunos antecedentes (en otras palabras, es mi culpa).

Answer 2

Primero revisaría el registro de compilación.

Si no es obvio a partir de eso, podría intentar incluir Console.WriteLines en las pruebas; no estoy seguro, pero creo que están escritas en el registro de compilación. Alternativamente, podría iniciar sesión en un archivo (incluso utilizando log4net si desea obtener más detalles).

Si tiene Visual Studio instalado en el servidor de CI, puede intentar ejecutar la compilación / pruebas desde allí. Si es un problema de conectividad, eso podría resolverlo.

Sin embargo, he visto problemas de ruta 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

Me encontré con esto hoy al crear algunas pruebas de integración que tienen una configuración de larga ejecución que no quiero duplicar. Terminé envolviendo toda la lógica de configuración del dispositivo de prueba en un try / catch. Luego agrego un método de configuración cuyo único propósito es ver si ocurrió 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 4

Estaba recibiendo el mismo error al ejecutar cualquier prueba con SpecFlow usando Visual NUnit. Cuando intenté hacer lo mismo desde el Explorador de pruebas de la unidad (proporcionado por Resharper), dio un mensaje un poco 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 mi base de datos de prueba correctamente haciendo un cambio rápido a VS Unit Testing. En mi caso fue capaz de devolver una mejor respuesta a la razón por la que falló. Suelo usar NUnit. " No se puede crear la instancia de clase X. Error: System.Data.SqlClient.SqlException: Se produjo un error de activación de archivo. El nombre del archivo físico '\ DbTest.mdf' puede ser incorrecto. Diagnosticar y corregir errores adicionales, y reintentar la operación. CREATE DATABASE falló. Algunos de los nombres de archivos en la lista no se pudieron crear. Verificar errores relacionados. "

Answer 6

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

Answer 7

Si está utilizando SpecFlow y C # en Visual Studio, mire el archivo < cualquiera que sea > .feature.cs generado automáticamente cuando la prueba falla. En la línea de clase parcial pública < lo que sea > Feature , debería ver un símbolo que, al pasar el cursor sobre, mostrará la razón por la 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 de BeforeTestRun , AfterTestRun , BeforeFeature y AfterFeature deben ser estáticos.

Answer 8

Tuve este problema y se debió a la adición de un Dictionary privado de solo lectura en la clase, de la misma manera que se agrega una string privada const .

Intenté hacer que Dictionary sea una constante, pero no puedes hacerlo en tiempo de compilación. Resolví esto poniendo mi Diccionario en un método que lo devuelve.

Answer 9

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

[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 10

Me preocupó esto hoy. Hice lo siguiente para obtener el error real.

(1) Escriba otra prueba en un dispositivo separado que inicialice una instancia del dispositivo de prueba problemático, llame explícitamente a los métodos de configuración como TestFixtureSetUp y SetUp si los hay, y luego ejecute el método de prueba objetivo.

(2) Agregue el código de manejo de excepciones para el nuevo código anterior y registre / produzca la excepción real en algún lugar.

Answer 11

En caso de que pueda ayudar a alguien: Puede capturar la excepción y escribirla en la consola en TearDown

Algo 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á:

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