Inicialización global de NUnit: ¿mala idea?

Question

Necesitamos algún código de configuración única mundial en nuestro conjunto de pruebas. Podemos hacerlo más de una vez, pero lleva bastante tiempo.

• Es requerido por todos los dispositivos para que [TestFixtureSetUp] no funcione. Tiene que ejecutarse antes del código [TestFixtureSetUp].

• Ponlo en Main() ya que mantenemos los ensambles de prueba como ejecutables. Sin embargo, Main no se ejecuta bajo el cliente GUI.

• La creación de una clase separada con un constructor estático para la inicialización solo funciona cuando se hace referencia a la clase que no favorecemos en todas y cada una de las clases.

• Heredar todos los accesorios de prueba de una clase base y agregarle un constructor estático provoca varias llamadas al código de inicio.

Ahora dadas las circunstancias, tengo dos preguntas:

1) ¿Es "configuración global" una muy mala idea que no está apoyada por NUnit?

2) ¿Cuál es la forma menos dolorosa y más común de lograr esto?

Answer 1

[SetUpFixture]

Este es el atributo que marca una clase que contiene la configuración o desmontaje métodos de una sola vez para todos los accesorios de la prueba en virtud de un espacio de nombres dado.

El método SetUp en un SetUpFixture se ejecuta una vez antes de cualquiera de los dispositivos incluidos en su espacio de nombres. El método TearDown se ejecuta una vez después de que todos los dispositivos han completado la ejecución.

Inicialización de ancho de conjunto. Si no coloca la clase en ningún espacio de nombre, se aplicará a todas las pruebas en el ensamblaje.

por ejemplo.

// using statements 

[SetUpFixture] 
public class GlobalSetup { 
    [SetUp] 
    public void ShowSomeTrace() { 
    Trace.WriteLine("It works..."); // won't actually trace 
    } 
} 

http://www.nunit.org/index.php?p=setupFixture&r=2.4

Answer 2

1) Supongo que depende del contexto. Nunca he necesitado una configuración global en ningún proyecto, pero puedo imaginar escenarios, p. una aplicación que solo lee datos y una configuración de datos global común.

2) Puede realizar su configuración global, p. en la base del accesorio que mencionas, con estado. Es decir. tener una propiedad HasRun o similar que esté marcada antes de la ejecución.

Answer 3

No creo que haya una forma agradable de hacerlo realidad desafortunadamente, probablemente porque NUnit está destinado principalmente a pruebas unitarias, y no debería necesitar ninguna configuración global para las pruebas unitarias (todo debería ser burlado localmente en cada accesorio de prueba).

Sin embargo, es bastante común usar NUnit para pruebas de integración, y allí es muy común tener una configuración global, como en su caso. Hay algunas opciones razonables aquí:

1. En mi proyecto actual, generalmente lo hacemos en el script msbuild que está ejecutando las pruebas. Los beneficios son que no necesita recordar acerca de una configuración especial cuando escribe nuevas pruebas. Lo malo: debes asegurarte de que tienes todo configurado cuando ejecutas las pruebas desde IDE.

2. Si lo anterior no es una opción, puede utilizar su última idea: heredar las pruebas de una clase base común. La clase base podría entonces hacer referencia a una clase de singleton (puede encontrar, por ejemplo, el artículo de Jon Skeets sobre cómo implementar un singleton), que haría la configuración. De esta forma se ejecutará solo una vez.

Answer 4

Como se indica en mi comentario, se puede lograr el montaje de ancho init mediante el uso de un SetUpFixture situado en la planta de montaje.Necesitaba esto para desactivar la interfaz de usuario en la escucha de seguimiento por defecto:

[SetUpFixture] 
public class AssemblySetup 
{ 
    [SetUp] 
    public void Setup() 
    { 
     var traceListener = Debug.Listeners.Cast<TraceListener>().FirstOrDefault(listener => listener is DefaultTraceListener) as DefaultTraceListener; 

     if (traceListener != null) 
      traceListener.AssertUiEnabled = false; 
    } 
} 

Más sobre el montaje o la configuración de espacio de nombres: http://www.nunit.org/index.php?p=setupFixture&r=2.4

Nota: Como se ha señalado por otros, no utilice este al aislamiento corrupta entre tus pruebas