¿Cómo ejecutar métodos de prueba en orden específico en JUnit4?

Si se deshace de su instancia existente de Junit y descarga JUnit 4.11 o superior en la ruta de compilación, el siguiente código ejecutará los métodos de prueba en el orden de sus nombres, ordenados en orden ascendente:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {

    @Test
    public void testAcreate() {
        System.out.println("first");
    }
    @Test
    public void testBupdate() {
        System.out.println("second");
    }
    @Test
    public void testCdelete() {
        System.out.println("third");
    }
}

Si el pedido es importante, debe realizarlo usted mismo.

@Test public void test1() { ... }
@Test public void test2() { test1(); ... }

En particular, debe enumerar algunas o todas las permutaciones de orden posibles para probar, si es necesario.

Por ejemplo,

void test1(); 
void test2(); 
void test3(); 


@Test
public void testOrder1() { test1(); test3(); }

@Test(expected = Exception.class)
public void testOrder2() { test2(); test3(); test1(); }

@Test(expected = NullPointerException.class)
public void testOrder3() { test3(); test1(); test2(); }

O, una prueba completa de todas las permutaciones:

@Test
public void testAllOrders() {
    for (Object[] sample: permute(1, 2, 3)) {
        for (Object index: sample) {
            switch (((Integer) index).intValue()) {
                case 1: test1(); break; 
                case 2: test2(); break; 
                case 3: test3(); break; 
            }
        }
    }
}

Aquí, permute() es una función simple que itera todas las permuaciones posibles en una Colección de matriz.

La migración a TestNG parece la mejor manera, pero no veo una solución clara aquí para JUnit. Aquí está la mayoría solución legible / formato que encontré para JUnit:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {
    @Test
    void stage1_prepareAndTest(){};

    @Test
    void stage2_checkSomething(){};

    @Test
    void stage2_checkSomethingElse(){};

    @Test
    void stage3_thisDependsOnStage2(){};

    @Test
    void callTimeDoesntMatter(){}
}

Esto asegura que los métodos stage2 se llamen después de los de stage1 y antes de los de stage3.

Es uno de los principales problemas que enfrenté cuando trabajé en Junit y se me ocurrió la siguiente solución que funciona bien para mí:

import java.util.ArrayList;
import java.util.Collections;
import java.util.Comparator;
import java.util.List;

import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.InitializationError;

public class OrderedRunner extends BlockJUnit4ClassRunner {

    public OrderedRunner(Class<?> clazz) throws InitializationError {
        super(clazz);
    }

    @Override
    protected List<FrameworkMethod> computeTestMethods() {
        List<FrameworkMethod> list = super.computeTestMethods();
        List<FrameworkMethod> copy = new ArrayList<FrameworkMethod>(list);
        Collections.sort(copy, new Comparator<FrameworkMethod>() {

            @Override
            public int compare(FrameworkMethod f1, FrameworkMethod f2) {
                Order o1 = f1.getAnnotation(Order.class);
                Order o2 = f2.getAnnotation(Order.class);

                if (o1 == null || o2 == null) {
                    return -1;
                }

                return o1.order() - o2.order();
            }
        });
        return copy;
    }
}

También cree una interfaz como la siguiente:

 @Retention(RetentionPolicy.RUNTIME)


@Target({ ElementType.METHOD})

public @interface Order {
public int order();
}

Ahora supongamos que tiene clase A donde ha escrito varios casos de prueba como los siguientes:

(@runWith=OrderRunner.class)
Class A{
@Test
@Order(order = 1)

void method(){

//do something

}

}

Así que la ejecución comenzará desde el método llamado "method()". ¡Gracias!

El (todavía inédito) el cambio https://github.com/junit-team/junit/pull/386 introduce un @SortMethodsWith. https://github.com/junit-team/junit/pull/293 al menos hizo el orden predecible sin eso (en Java 7 puede ser bastante aleatorio).

Mira un informe JUnit. JUnit ya está organizado por paquete. Cada paquete tiene (o puede tener) clases TestSuite, cada una de las cuales a su vez ejecuta varios casos de prueba. Cada TestCase puede tener múltiples métodos de prueba de la forma public void test*(), cada uno de los cuales se convertirá en una instancia de la clase TestCase a la que pertenecen. Cada método de prueba (instancia TestCase) tiene un nombre y un criterio de aprobado/no aprobado.

Lo que mi gestión requiere es el concepto de elementos individuales TestStep , cada uno de los cuales informa sus propios criterios de aprobación/reprobación. El fracaso de cualquier etapa de prueba no impedirá la ejecución de las etapas de prueba posteriores.

En el pasado, los desarrolladores de test en mi posición organizaban las clases TestCase en paquetes que correspondían a la(s) parte (s) del producto bajo prueba, creaban una clase TestCase para cada prueba, e hacían de cada método de prueba un "paso" separado en la prueba, completo con sus propios criterios de aprobación/fallo en la salida JUnit. Cada caso de prueba es una "prueba" independiente, pero el los métodos individuales, o "pasos" de prueba dentro del caso de prueba, deben ocurrir en un orden específico.

Los métodos TestCase eran los pasos del TestCase, y los diseñadores de pruebas obtuvieron un criterio de aprobado/no aprobado por separado por paso de prueba. Ahora los pasos de la prueba están mezclados, y las pruebas (por supuesto) fallan.

Por ejemplo:

Class testStateChanges extends TestCase

public void testCreateObjectPlacesTheObjectInStateA()
public void testTransitionToStateBAndValidateStateB()
public void testTransitionToStateCAndValidateStateC()
public void testTryToDeleteObjectinStateCAndValidateObjectStillExists()
public void testTransitionToStateAAndValidateStateA()
public void testDeleteObjectInStateAAndObjectDoesNotExist()
public void cleanupIfAnythingWentWrong()

Cada método de ensayo afirma e informa de sus propios criterios de aprobación/reprobación. Colapsar esto en "un gran método de prueba" por el bien de ordenar pierde el pase / suspenso criterios granularidad de cada "paso" en el informe de resumen de JUnit. ...y eso molesta a mis gerentes. Actualmente están exigiendo otra alternativa.

¿Puede alguien explicar cómo un JUnit con orden de método de prueba codificado soportaría criterios de aprobación/reprobación separados de cada paso de prueba secuencial, como se ejemplificó anteriormente y requerido por mi administración?

Independientemente de la documentación, veo esto como una regresión seria en el marco de JUnit que está haciendo la vida difícil para muchos desarrolladores de pruebas.

Lo que desea es perfectamente razonable cuando los casos de prueba se ejecutan como una suite.

Desafortunadamente no hay tiempo para dar una solución completa en este momento, pero echa un vistazo a la clase:

org.junit.runners.Suite

Que le permite llamar casos de prueba (desde cualquier clase de prueba) en un orden específico.

Estos pueden ser utilizados para crear pruebas funcionales, de integración o del sistema.

Esto deja sus pruebas unitarias como están sin un orden específico (como se recomienda), ya sea que las ejecute de esa manera o no, y luego reutilizar las pruebas como parte de un panorama más amplio.

Reutilizamos/heredamos el mismo código para pruebas de unidad, integración y sistema, a veces basadas en datos, a veces basadas en confirmaciones y a veces ejecutadas como una suite.

No estoy seguro de estar de acuerdo, Si quiero probar 'File Upload' y luego probar 'Data Inserted by File Upload' ¿por qué no querría que estos fueran independientes unos de otros? Creo que es perfectamente razonable poder ejecutarlos por separado en lugar de tener ambos en un caso de prueba de Goliat.

Vea mi solución aquí: "Junit and java 7."

En este artículo describo cómo ejecutar pruebas junit en orden - "al igual que en su código fuente". Las pruebas se ejecutarán, en el orden en que sus métodos de prueba aparezcan en el archivo de clase.

Http://intellijava.blogspot.com/2012/05/junit-and-java-7.html

Pero como dijo Pascal Thivent, esta no es una buena práctica.

He leído algunas respuestas y estoy de acuerdo en que no es la mejor práctica, pero la forma más fácil de ordenar sus pruebas - y la forma en que JUnit ejecuta las pruebas por defecto es por nombre alfabético ascendente.

Así que simplemente nombra tus pruebas en el orden alfabético que quieras. También tenga en cuenta que el nombre de la prueba debe comenzar con la palabra prueba. Solo ten cuidado con los números

Test12 se ejecutará antes de test2

Entonces:

TestA_MyFirstTest testC_ThirdTest testB_ATestThatRunsSecond

Por favor, echa un vistazo a este: https://github.com/TransparentMarket/junit . Ejecuta la prueba en el orden en que se especifica (definido dentro del archivo de clase compilado). También cuenta con una suite AllTests para ejecutar pruebas definidas por subpaquete primero. Usando la implementación de AllTests se puede extender la solución también filtrando propiedades (solíamos usar anotaciones @ Fast, pero aún no se habían publicado).

Aquí hay una extensión de JUnit que puede producir el comportamiento deseado: https://github.com/aafuks/aaf-junit

Sé que esto va en contra de los autores de la filosofía JUnit, pero cuando se utiliza JUnit en entornos que no son pruebas unitarias estrictas (como se practica en Java) esto puede ser muy útil.

Terminé aquí pensando que mis pruebas no se ejecutaban en orden, pero la verdad es que el lío estaba en mis trabajos asincrónicos. Al trabajar con concurrencia, también debe realizar comprobaciones de concurrencia entre las pruebas. En mi caso, los trabajos y las pruebas comparten un semáforo, por lo que las siguientes pruebas se cuelgan hasta que el trabajo en ejecución libere el bloqueo.

Sé que esto no está completamente relacionado con esta pregunta, pero tal vez podría ayudar a apuntar al problema correcto

Puedes usar uno de estos códigos:

@FixMethodOrder(MethodSorters.JVM)OR `@FixMethodOrder(MethodSorters.DEFAULT)` OR `@FixMethodOrder(MethodSorters.NAME_ASCENDING)` before your test class like this:


@FixMethodOrder(MethodSorters.NAME_ASCENDING)


public class BookTest { ...}

JUnit actualmente permite que los métodos de prueba ejecuten el orden usando anotaciones de clase:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
@FixMethodOrder(MethodSorters.JVM)
@FixMethodOrder(MethodSorters.DEFAULT)

Para establecer el orden de los métodos, puede nombrarlos como:

A_testWorkUnit_WithCertainState_ShouldDoSomething b_testWorkUnit_WithCertainState_ShouldDoSomething c_testWorkUnit_WithCertainState_ShouldDoSomething

Puedes encontrar ejemplos aquí.