Orden de ejecución de prueba de NUnit


110

De forma predeterminada, las pruebas nunit se ejecutan alfabéticamente. ¿Alguien sabe de alguna forma de establecer la orden de ejecución? ¿Existe un atributo para esto?


7
Por qué querrías hacer esto? Parece que tiene una dependencia en el orden de ejecución, lo cual es malo. Debes reconsiderar por qué quieres esto. Las pruebas unitarias deben ejecutarse de forma aislada y ser totalmente independientes de las demás. Parece que está creando candidatos para la prueba de olor Pruebas erráticas .
RichardOD

Esto parece un duplicado, pero puede ver mi respuesta aquí
Johnno Nolan

12
@RichardOD - ¡debería! = Debe. Y realmente no es un evento obligatorio, porque en realidad casi todas las pruebas de integración se ejecutan en orden; pregúntele al equipo de control de calidad si aleatorizan el orden de sus pruebas.
tymtam

4
Actualmente tengo algunas pruebas cuyo orden parece importar aunque no debería. Personalmente, me gustaría una forma de aleatorizar el orden de la prueba específicamente para ayudarme a asegurar que mis pruebas NO DEBEN de alguna manera depender del orden. Por supuesto, lo que REALMENTE me gustaría sería un corredor de pruebas que ejecutara todas mis pruebas en orden aleatorio hasta que encuentre un problema, o yo diga que pare. Si ejecutaba eso durante la noche y todo seguía verde por la mañana, entonces podría estar seguro de haber eliminado el último de los efectos secundarios no deseados.
Mel

1
esta pregunta sería más relevante si la pregunta se actualizara para especificar que estamos hablando de pruebas de integración aquí ... Todos conocemos las reglas sobre las pruebas unitarias, al menos si ha leído los patrones de prueba de XUnit y ha seguido al tío Bob, etc. sí ... pero los marcos como NUnit también son realmente útiles para poner en marcha las pruebas de integración rápidamente ... y definitivamente no quiere que sean aleatorias, especialmente cuando se trata de una configuración de base de datos costosa ..
nrjohnstone

Respuestas:


51

Las pruebas unitarias deben poder ejecutarse de forma independiente y autónoma. Si cumplen este criterio, el orden no importa.

Sin embargo, hay ocasiones en las que querrá ejecutar ciertas pruebas primero. Un ejemplo típico es una situación de integración continua donde algunas pruebas duran más que otras. Usamos el atributo de categoría para poder ejecutar las pruebas que usan burlarse antes de las pruebas que usan la base de datos.

es decir, ponga esto al comienzo de sus pruebas rápidas

[Category("QuickTests")]

Cuando tenga pruebas que dependan de ciertas condiciones ambientales, considere los atributos TestFixtureSetUp y TestFixtureTearDown , que le permiten marcar métodos para ejecutar antes y después de sus pruebas.


2
@Chris, tiendo a no usar estos atributos, esta es una publicación de blog interesante: jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html . Sin embargo, un buen punto sobre las pruebas de categoría.
RichardOD

29
Otro ejemplo de pruebas dependientes de pedidos es cuando desea utilizar su marco nunit para ejecutar una prueba de integración ...
Byron Ross

1
@ByronRoss: Tiendo a hacer pruebas más grandes cuando hago eso, y me apoyo en las pruebas unitarias existentes tanto como sea posible para poder escribir menos pruebas. Entonces, cada ejecución completa puede fallar por separado. También trato de diseñar mis datos para que puedan vivir separados de los datos existentes, en lugar de depender de los datos existentes.
Merlyn Morgan-Graham

1
Si no ejecuta sus pruebas en orden aleatorio, ¿cómo puede verificar que realmente funcionen cuando se agotan? Lo que está diciendo es análogo a decir "Si su software no tiene errores, la prueba es sencilla".
jforberg

@jforberg: Si tiene una falla que ocurre al azar, ¿cómo dice cuando la ha solucionado?
NeedHack

175

Solo quiero señalar que, si bien la mayoría de los que respondieron asumieron que se trataba de pruebas unitarias, la pregunta no especificó que lo fueran.

nUnit es una gran herramienta que se puede utilizar para una variedad de situaciones de prueba. Puedo ver las razones apropiadas para querer controlar el orden de prueba.

En esas situaciones he tenido que recurrir a incorporar una orden de ejecución en el nombre de la prueba. Sería fantástico poder especificar el orden de ejecución mediante un atributo.


¿Quiere decir que llamó a sus pruebas, por ejemplo, 001_first_test 002_second_testy así sucesivamente?
cenizas999

Sí, así es, aunque normalmente uso un patrón que me permite insertar pruebas fácilmente si es necesario, así que tal vez 010_first_test, 020_second_test, etc.
Les

83
Gracias por la única respuesta sana aquí. Esta es una pregunta específica, pero de alguna manera se están votando respuestas vagas y pedantes. Sí, todos sabemos qué deben ser las pruebas unitarias, aunque esa no es la cuestión.
Egor Pavlikhin

1
Usted debe no confiar en el orden de ejecución de ser alfabético. Muchos corredores de pruebas ejecutan sus pruebas simultáneamente en muchos subprocesos o procesos y no necesariamente en orden alfabético. Por ejemplo, NCrunch prioriza las pruebas en función del código que cambie (pruebas impactadas), luego en si fallaron la última vez y luego en si se ejecutaron rápida o lentamente. Si desea un orden definido , simplemente cree un meta-corredor para esas pruebas y exclúyalo de las ejecuciones regulares.
Abel

3
Otra buena razón para especificar el orden es detectar ciertos problemas primero antes de continuar con el resto del conjunto de pruebas. en otras palabras, si mi prueba para crear un usuario falla, entonces no necesito que se ejecute todo lo demás antes de descubrir este resultado. En mi otra prueba probablemente me burlo del usuario, pero es importante para mí que esta sea la primera prueba en fallar, especialmente cuando el conjunto de pruebas es grande.
Bron Davies

125

NUnit 3.2.0 agregó un OrderAttribute, ver:

https://github.com/nunit/docs/wiki/Order-Attribute

Ejemplo:

public class MyFixture
{
    [Test, Order(1)]
    public void TestA() { ... }


    [Test, Order(2)]
    public void TestB() { ... }

    [Test]
    public void TestC() { ... }
}

5
Gracias, directo al punto de lo que estaba buscando, y sin discusiones, por qué es bueno o malo :)
aknoepfel

1
Y luego lo convierten en un número entero, en lugar de decimal, por lo que si uno tiene que insertar una prueba, todas las pruebas deben volver a numerarse.
epitka

Siempre puede comenzar con números muy grandes como millones o algo así si desea introducir elementos intermedios de esa manera, solo más escritura. Imo debería haber una manera más fácil de ordenar las cosas que usar números para la prioridad como un árbol de dependencia de métodos, pero cada uno tiene sus propias desventajas / ventajas.
Răzvan Flavius ​​Panda

9
Buena respuesta, pero cuidado, la documentación indica que las pruebas no esperan a que finalicen las pruebas anteriores.
ROX

Curiosamente, en mi experiencia, si agregamos los atributos Test y Order por separado, no hay garantía de ordenar las pruebas.
AT

22

Querer que las pruebas se ejecuten en un orden específico no significa que las pruebas sean dependientes entre sí; estoy trabajando en un proyecto TDD en este momento y, siendo un buen TDDer, me he burlado / eliminado de todo, pero haría sería más legible si pudiera especificar el orden en que se muestran los resultados de las pruebas , temáticamente en lugar de alfabéticamente. Hasta ahora, lo único que se me ocurre es anteponer a_ b_ c_ a las clases, las clases, los espacios de nombres y los métodos. (No es bueno) Creo que un atributo [TestOrderAttribute] sería bueno, no seguido estrictamente por el marco, sino una pista para que podamos lograr esto


10

Independientemente de si las pruebas dependen del orden o no ... algunos de nosotros solo queremos controlar todo, de manera ordenada.

Las pruebas unitarias generalmente se crean en orden de complejidad. Entonces, ¿por qué no deberían ejecutarse también en orden de complejidad o en el orden en que fueron creados?

Personalmente, me gusta ver las pruebas ejecutadas en el orden en que las creé. En TDD, cada prueba sucesiva naturalmente será más compleja y llevará más tiempo ejecutarla. Preferiría ver que la prueba más simple falla primero, ya que será un mejor indicador de la causa de la falla.

Pero también puedo ver el beneficio de ejecutarlos en orden aleatorio, especialmente si desea probar que sus pruebas no tienen dependencias de otras pruebas. ¿Qué le parece agregar una opción para probar a los corredores a "Ejecutar pruebas al azar hasta que se detenga"?


9

Estoy probando con Selenium en un sitio web bastante complejo y todo el conjunto de pruebas puede ejecutarse durante más de media hora, y aún no estoy cerca de cubrir toda la aplicación. Si tengo que asegurarme de que todos los formularios anteriores se completen correctamente para cada prueba, esto agrega una gran cantidad de tiempo, no solo una pequeña cantidad de tiempo, a la prueba general. Si hay demasiada sobrecarga para ejecutar las pruebas, las personas no las ejecutarán con la frecuencia que deberían.

Entonces, los pongo en orden y dependo de pruebas anteriores para tener cuadros de texto y demás completados. Utilizo Assert.Ignore () cuando las condiciones previas no son válidas, pero necesito que se ejecuten en orden.


1
Totalmente. Estoy en el mismo barco aquí.
Sleeper Smith

¡Yo también! ¡Exactamente por qué llegué a esta pregunta!
Niklas Wulff

@NiklasRingdahl si está usando Visual Studio con nunit, descargue nunit y use pruebas de MS. luego puede utilizar el archivo de prueba ordenada de Visual Studio para organizar los casos de prueba en el orden en que desea que se ejecuten
Rahul Lodha

@RahulLodha ¡Gracias! Lo investigaré.
Niklas Wulff

9

Realmente me gusta la respuesta anterior.

Lo cambié un poco para poder usar un atributo para establecer el rango de orden:

namespace SmiMobile.Web.Selenium.Tests
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Reflection;
    using NUnit.Framework;

    public class OrderedTestAttribute : Attribute
    {
        public int Order { get; set; }


        public OrderedTestAttribute(int order)
        {
            Order = order;
        }
    }

    public class TestStructure
    {
        public Action Test;
    }

    class Int
    {
        public int I;
    }

    [TestFixture]
    public class ControllingTestOrder
    {
        private static readonly Int MyInt = new Int();

        [TestFixtureSetUp]
        public void SetUp()
        {
            MyInt.I = 0;
        }

        [OrderedTest(0)]
        public void Test0()
        {
            Console.WriteLine("This is test zero");
            Assert.That(MyInt.I, Is.EqualTo(0));
        }

        [OrderedTest(2)]
        public void ATest0()
        {
            Console.WriteLine("This is test two");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(2));
        }


        [OrderedTest(1)]
        public void BTest0()
        {
            Console.WriteLine("This is test one");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(1));
        }

        [OrderedTest(3)]
        public void AAA()
        {
            Console.WriteLine("This is test three");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(3));
        }


        [TestCaseSource(sourceName: "TestSource")]
        public void MyTest(TestStructure test)
        {
            test.Test();
        }

        public IEnumerable<TestCaseData> TestSource
        {
            get
            {
                var assembly =Assembly.GetExecutingAssembly();
                Dictionary<int, List<MethodInfo>> methods = assembly
                    .GetTypes()
                    .SelectMany(x => x.GetMethods())
                    .Where(y => y.GetCustomAttributes().OfType<OrderedTestAttribute>().Any())
                    .GroupBy(z => z.GetCustomAttribute<OrderedTestAttribute>().Order)
                    .ToDictionary(gdc => gdc.Key, gdc => gdc.ToList());

                foreach (var order in methods.Keys.OrderBy(x => x))
                {
                    foreach (var methodInfo in methods[order])
                    {
                        MethodInfo info = methodInfo;
                        yield return new TestCaseData(
                            new TestStructure
                                {
                                    Test = () =>
                                        {
                                            object classInstance = Activator.CreateInstance(info.DeclaringType, null);
                                            info.Invoke(classInstance, null);
                                        }
                                }).SetName(methodInfo.Name);
                    }
                }

            }
        }
    }
}

Creo que este enfoque es genial. Sin embargo, tenga en cuenta que el código de reflexión extraerá todos los métodos con el atributo, por lo que si está intentando ejecutar un dispositivo de prueba específico, se sorprenderá al descubrir que se ejecuta más de lo que pensaba. Puede modificar fácilmente la consulta LINQ si este no es el comportamiento deseado. Consulte los enlaces en mi respuesta para obtener más información.
Chrispy

OrderedTestya no es compatible con NUnit 3.
Conrad

7

Sé que esta es una publicación relativamente antigua, pero aquí hay otra forma de mantener su prueba en orden SIN hacer que los nombres de la prueba sean incómodos. Al usar el atributo TestCaseSource y hacer que el objeto que pasa tenga un delegado (Acción), no solo puede controlar totalmente el orden, sino también nombrar la prueba como es.

Esto funciona porque, de acuerdo con la documentación, los elementos de la colección devueltos desde la fuente de prueba siempre se ejecutarán en el orden en que se enumeran.

Aquí hay una demostración de una presentación que daré mañana:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace NUnitTest
{
    public class TestStructure
    {
        public Action Test;
    }

    class Int
    {
        public int I;
    }

    [TestFixture]
    public class ControllingTestOrder
    {
        private static readonly Int MyInt= new Int();

        [TestFixtureSetUp]
        public void SetUp()
        {
            MyInt.I = 0;
        }

        [TestCaseSource(sourceName: "TestSource")]
        public void MyTest(TestStructure test)
        {
            test.Test();
        }

        public IEnumerable<TestCaseData> TestSource
        {
            get
            {
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test one");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(1));
                        }
                    }).SetName(@"Test One");
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test two");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(2));
                        }
                    }).SetName(@"Test Two");
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test three");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(3));
                        }
                    }).SetName(@"Test Three");
            }
        }
    }
}

Utilizo este patrón para las pruebas de integración en paralelo que llevarían demasiado tiempo para ejecutarse linealmente. Todas las pruebas son de un tipo, así que uso una acción <T in>, y cada acción tiene una clave que dice lo que hace "ShouldBeFoo". De esta manera, lo que hace la prueba será visible en el nombre de la prueba, y TestCaseSource se puede filtrar para que se agrupen diferentes tipos de pruebas. Irónicamente, no me importa la orden de ejecución, pero estoy de acuerdo en que funcionaría.
Novaterata

Usar el TestCaseSourcecomo una forma de ejecutar pruebas ordenadas es un golpe de genialidad. Bien hecho. He adoptado este enfoque junto con el siguiente y agregué algunas modificaciones adicionales para que sea más fácil de usar. Vea los enlaces en mi respuesta para obtener información adicional, ¡pero la idea subyacente proviene de esta gran respuesta!
Chrispy

Lamentablemente, con NUnit 3, la fuente de TestCaseSourcedebe ser estática, lo que impide el uso de patrones. Gorrón.
Conrad

@Conrad. No veo qué diferencia hace el método estático o no. La prueba aún regresa en orden de cualquier manera.
Dave Bush

No es el método que debe ser estático: la fuente (variable o propiedad) de TestCaseSourcedebe ser un objeto estático en NUnit 3, o las pruebas no se ejecutarán. Y no puede crear objetos dinámicos dentro de un objeto estático. Por eso no funcionará en el v. 3.
Conrad

5

Estoy trabajando con casos de prueba de IU de extremo a extremo de Selenium WebDriver escritos en C #, que se ejecutan usando el marco NUnit. (No casos unitarios como tales)

Estas pruebas de IU ciertamente dependen del orden de ejecución, ya que otras pruebas deben agregar algunos datos como condición previa. (No es factible seguir los pasos en todas las pruebas)

Ahora, después de agregar el décimo caso de prueba, veo que NUnit quiere ejecutarse en este orden: Test_1 Test_10 Test_2 Test_3 ..

Así que supongo que también tengo que alfabetizar los nombres de los casos de prueba por ahora, pero sería bueno tener esta pequeña característica de controlar el orden de ejecución agregada a NUnit.


9
No estoy de acuerdo con Arran: las pruebas de IU son inherentemente secuencias de pequeños pasos. Cada paso debe ser una prueba (Razón: si falla, necesito saber qué paso). Las secuencias pueden ser independientes, pero dentro de una secuencia, el orden importa y es necesario detenerse en caso de falla.
Zasz

3

Por lo general, la prueba unitaria debe ser independiente, pero si debe hacerlo, puede nombrar sus métodos en orden alfabético, por ejemplo:

[Test]
public void Add_Users(){}

[Test]
public void Add_UsersB(){}

[Test]
public void Process_Users(){}

o puedes hacerlo ..

        private void Add_Users(){}

        private void Add_UsersB(){}

        [Test]
        public void Process_Users()
        {
           Add_Users();
           Add_UsersB();
           // more code
        }

2
Excepto que ahora los nombres deben estar en orden alfabético, lo cual es una pésima solución. :(

@ user166390 - no, no es horrible. Funciona y depende del comportamiento documentado de NUnit.
tymtam

➕1 lo suficientemente bueno para mí, mucho más fácil si comienza sus pruebas con a_ b_ t1_, en su t2_lugar , o confiando en caracteres finales fáciles de perder
Chris Marisic

3

Hay muy buenas razones para utilizar un mecanismo de pedido de prueba. La mayoría de mis propias pruebas utilizan buenas prácticas, como configuración / desmontaje. Otros requieren una gran cantidad de configuración de datos, que luego se pueden usar para probar una variedad de funciones. Hasta ahora, he usado pruebas grandes para manejar estas pruebas de integración (Selenium Webdriver). Sin embargo, creo que la publicación sugerida anteriormente en https://github.com/nunit/docs/wiki/Order-Attribute tiene mucho mérito. Aquí hay un ejemplo de por qué ordenar sería extremadamente valioso:

  • Uso de Selenium Webdriver para ejecutar una prueba para descargar un informe
  • El estado del informe (ya sea descargable o no) se almacena en caché durante 10 minutos.
  • Eso significa que, antes de cada prueba, necesito restablecer el estado del informe y luego esperar hasta 10 minutos antes de que se confirme que el estado ha cambiado, y luego verificar que el informe se descargue correctamente.
  • Los informes no se pueden generar de manera práctica / oportuna mediante simulacros o cualquier otro mecanismo dentro del marco de prueba debido a su complejidad.

Este tiempo de espera de 10 minutos ralentiza el conjunto de pruebas. Cuando multiplica retrasos de almacenamiento en caché similares en una multitud de pruebas, consume mucho tiempo. Solicitar pruebas podría permitir que la configuración de datos se realice como una "Prueba" justo al comienzo de la serie de pruebas, con pruebas que dependan de la caché para que se ejecuten hacia el final de la ejecución de la prueba.


2

Esta pregunta es realmente antigua ahora, pero para las personas que pueden llegar a esto mediante la búsqueda, tomé las excelentes respuestas de user3275462 y PvtVandals / Rico y las agregué a un repositorio de GitHub junto con algunas de mis propias actualizaciones. También creé una publicación de blog asociada con información adicional que puede consultar para obtener más información.

Espero que esto sea útil para todos ustedes. Además, a menudo me gusta usar el atributo Categoría para diferenciar mis pruebas de integración u otras pruebas de un extremo a otro de mis pruebas unitarias reales. Otros han señalado que las pruebas unitarias no deben tener una dependencia de orden, pero otros tipos de pruebas a menudo sí, por lo que esto proporciona una buena manera de ejecutar solo la categoría de pruebas que desea y también ordenar esas pruebas de un extremo a otro.


¿Pueden ayudarme con un problema que tengo? Aquí está el enlace: stackoverflow.com/questions/31281395/…
Morgan Soren

1

Me sorprende que la comunidad NUnit no haya encontrado nada, así que fui a crear algo como esto yo mismo.

Actualmente estoy desarrollando una biblioteca de código abierto que le permite ordenar sus pruebas con NUnit. Puede pedir accesorios de prueba y pedir "especificaciones de prueba ordenadas" por igual.

La biblioteca ofrece las siguientes características:

  • Cree jerarquías complejas de ordenación de pruebas
  • Omitir pruebas posteriores si falla una prueba en orden
  • Ordene sus métodos de prueba por dependencia en lugar de orden de números enteros
  • Admite el uso en paralelo con pruebas desordenadas. Las pruebas no ordenadas se ejecutan primero.

La biblioteca está realmente inspirada en cómo MSTest prueba los pedidos con .orderedtestarchivos. Mire un ejemplo a continuación.

[OrderedTestFixture]
public sealed class MyOrderedTestFixture : TestOrderingSpecification {
    protected override void DefineTestOrdering() {
        TestFixture<Fixture1>();

        OrderedTestSpecification<MyOtherOrderedTestFixture>();

        TestFixture<Fixture2>();
        TestFixture<Fixture3>();
    }

    protected override bool ContinueOnError => false; // Or true, if you want to continue even if a child test fails
}

1

Si está utilizando [TestCase], el argumento TestNameproporciona un nombre para la prueba.

Si no se especifica, se genera un nombre basado en el nombre del método y los argumentos proporcionados.

Puede controlar el orden de ejecución de la prueba como se indica a continuación:

                    [Test]
            [TestCase("value1", TestName = "ExpressionTest_1")]
            [TestCase("value2", TestName = "ExpressionTest_2")]
            [TestCase("value3", TestName = "ExpressionTest_3")]
            public void ExpressionTest(string  v)
            {
                //do your stuff
            }

Aquí utilicé el "ExpressionTest"sufijo del nombre del método con un número.

Puede utilizar cualquier nombre ordenado alfabéticamente, consulte el atributo TestCase


0

No debe depender del orden en el que el marco de pruebas selecciona las pruebas para su ejecución. Las pruebas deben ser aisladas e independientes. En el sentido de que no deben depender de que otra prueba les prepare el escenario o limpie después de ellos. También deben producir el mismo resultado independientemente del orden de ejecución de las pruebas (para una instantánea determinada del IVU)

Busqué un poco en Google. Como de costumbre, algunas personas han recurrido a trucos furtivos (en lugar de resolver el problema subyacente de capacidad de prueba / diseño

  • nombrar las pruebas en orden alfabético de modo que las pruebas aparezcan en el orden en que 'necesitan' ejecutarse. Sin embargo, NUnit puede optar por cambiar este comportamiento con una versión posterior y luego sus pruebas se eliminarán. Es mejor comprobar los binarios NUnit actuales en Source Control.
  • VS (en mi humilde opinión, fomentando el comportamiento incorrecto con sus 'herramientas ágiles') tiene algo llamado como "pruebas ordenadas" en su marco de pruebas de MS. No perdí el tiempo leyendo, pero parece estar dirigido a la misma audiencia.

Ver también: características de una buena prueba


Hay ocasiones en las que le gustaría que las pruebas de ejecución más rápida se ejecuten antes de las pruebas de ejecución prolongada, específicamente en las pruebas de integración y aceptación. Por ejemplo, en una aplicación de blogs: primero prueba el inicio de sesión, porque si esa función no funciona, la publicación tampoco funcionará, por lo que no tiene sentido ejecutar esa prueba (puede detener el corredor manualmente). Pero si intenta seguir realizando pruebas, llevará más tiempo.
Marcel Valdez Orozco

@MarcelValdezOrozco: puede lograr ese objetivo dividiendo sus pruebas a través de diferentes dll físicos o usando etiquetas / categorías. Puede crear sus scripts de compilación para ejecutar dlls / categorías en orden. En general, permitir la ordenación de pruebas generalmente conduce a pruebas acopladas que desarrollan dependencias de las pruebas vecinas (con el tiempo, por supuesto). AFAIR en el próximo gran lanzamiento de NUnit, admitirá un orden diferente de pruebas, por ejemplo, aleatorio, etc.
Gishu

2
Particionar más el mismo tipo de pruebas (pruebas de aceptación, por ejemplo) no tiene sentido, y separarlas en otra DLL aumenta innecesariamente la complejidad en todas partes: código fuente, scripts de compilación, scripts de prueba, estructura del proyecto, etc. Solo para hacer un simple reordenamiento de los exámenes.
Marcel Valdez Orozco

Emitir (básicamente, todas las bibliotecas burlonas) es una razón por la que el orden sería importante. No puede descargar el dominio de su aplicación, y nunit runner (si ejecuta todas las pruebas en un ensamblado) mantiene ese dominio para todas las pruebas en al menos esa 'solución'. Si una prueba crea tipos para probar algo y otra prueba entra en conflicto con ese tipo creado, debido al orden, esa no es una prueba defectuosa. Están aislados lógicamente, es solo que nUnit no proporciona un aislamiento adecuado entre cada 'prueba' en sí.
Kelly Elton

6
Esta es una respuesta bastante condescendiente y la hace divertida porque en realidad solo se aplica a las pruebas unitarias e ignora por completo ser pragmático.
tymtam

0

En caso de usar TestCaseSourcela clave es el override string ToStringmétodo, cómo funciona:

Suponga que tiene la clase TestCase

public class TestCase
{
    public string Name { get; set; }
    public int Input { get; set; }
    public int Expected { get; set; }
}

Y una lista de TestCases:

private static IEnumerable<TestCase> TestSource()
{
    return new List<TestCase>
    {
        new TestCase()
        {
           Name = "Test 1",
           Input = 2,
           Expected = 4
        },
        new TestCase()
        {
            Name = "Test 2",
            Input = 4,
            Expected = 16
        },
        new TestCase()
        {
            Name = "Test 3",
            Input = 10,
            Expected = 100
        }
    };
}

Ahora usémoslo con un método de prueba y veamos qué sucede:

[TestCaseSource(nameof(TestSource))]
public void MethodXTest(TestCase testCase)
{
    var x = Power(testCase.Input);
    x.ShouldBe(testCase.Expected);
}

Esto no se probará en orden y la salida será así:

ingrese la descripción de la imagen aquí

Entonces, si agregamos override string ToStringa nuestra clase como:

public class TestCase
{
    public string Name { get; set; }
    public int Input { get; set; }
    public int Expected { get; set; }

    public override string ToString()
    {
        return Name;
    }
}

El resultado cambiará y obtendremos el orden y el nombre de la prueba como:

ingrese la descripción de la imagen aquí

Nota:

  1. Este es solo un ejemplo para ilustrar cómo obtener el nombre y el orden en la prueba, el orden se toma numéricamente / alfabéticamente, por lo que si tiene más de diez pruebas, sugiero hacer la Prueba 01, Prueba 02 ... Prueba 10, Prueba 11, etc.porque si haces la Prueba 1 y en algún momento la Prueba 10, el orden será Prueba 1, Prueba 10, Prueba 2 ... etc.
  2. La entrada y Esperado pueden ser de cualquier tipo, cadena, objeto o clase personalizada.
  3. Además del orden, lo bueno aquí es que ves el nombre de la prueba, que es más importante.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.