Как запустить методы тестирования в определенном порядке в JUnit4?

Я хочу выполнить тестовые методы, которые аннотируются @Testв определенном порядке.

Например:

public class MyTest {
    @Test public void test1(){}
    @Test public void test2(){}
}

Я хочу убедиться, чтобы бежать test1()раньшеtest2() каждым запуском MyTest, но я не смог найти аннотацию вроде @Test(order=xx).

Я думаю, что это очень важная функция для JUnit, если автору JUnit не нужна функция заказа , почему?

Я думаю, что это очень важная функция для JUnit, если автору JUnit не нужна функция заказа, почему?

Я не уверен, что есть чистый способ сделать это с помощью JUnit, насколько мне известно, JUnit предполагает, что все тесты могут выполняться в произвольном порядке. Из FAQ:

Как мне использовать тестовый прибор?

(...) Порядок вызовов методов теста не гарантируется , поэтому testOneItemCollection () может быть выполнен до testEmptyCollection (). (...)

Почему это так? Что ж, я считаю, что создание порядка выполнения тестов - это практика, которую авторы не хотят продвигать. Тесты должны быть независимыми, они не должны быть соединены и нарушающим это будет сделать все труднее поддерживать, сломается возможность запускать тесты по отдельности ( что очевидно), и т.д.

При этом, если вы действительно хотите пойти в этом направлении, рассмотрите возможность использования TestNG, поскольку он поддерживает запуск методов испытаний в любом произвольном порядке (и такие вещи, как указание, что методы зависят от групп методов). Седрик Беуст объясняет, как это сделать в порядке выполнения тестов в testng .

Если вы избавитесь от существующего экземпляра Junit и загрузите JUnit 4.11 или выше по пути сборки, следующий код выполнит методы тестирования в порядке их имен, отсортированных в порядке возрастания:

@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");
    }
}

Если заказ важен, вы должны сделать заказ самостоятельно.

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

В частности, вы должны перечислить некоторые или все возможные варианты заказа для проверки, если это необходимо.

Например,

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(); }

Или полный тест всех перестановок:

@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; 
            }
        }
    }
}

Вот permute()простая функция, которая перебирает все возможные перестановки в коллекцию массивов.

Миграция на TestNG кажется лучшим способом, но я не вижу здесь четкого решения для jUnit. Вот наиболее читаемое решение / форматирование, которое я нашел для 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(){}
}

Это гарантирует, что методы stage2 вызываются после stage1 и перед stage3.

Это одна из главных проблем, с которой я столкнулся, когда работал над Junit, и я нашел следующее решение, которое отлично работает для меня:

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;
    }
}

также создайте интерфейс как ниже:

 @Retention(RetentionPolicy.RUNTIME)


@Target({ ElementType.METHOD})

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

Теперь предположим, что у вас есть класс A, в котором вы написали несколько тестов, как показано ниже:

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

void method(){

//do something

}

}

Таким образом, выполнение начнется с метода с именем "method ()". Спасибо!

JUnit в настоящее время позволяет тестовым методам выполнять упорядочение с использованием аннотаций классов:

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

По умолчанию методы испытаний запускаются в алфавитном порядке. Итак, чтобы установить определенный порядок методов, вы можете назвать их как:

a_TestWorkUnit_WithCertainState_ShouldDoSomething b_TestWorkUnit_WithCertainState_ShouldDoSomething c_TestWorkUnit_WithCertainState_ShouldDoSomething

Вы можете найти примеры здесь .

Изменение (пока не выпущенное) https://github.com/junit-team/junit/pull/386 представляет собой @SortMethodsWith. https://github.com/junit-team/junit/pull/293 по крайней мере сделал заказ предсказуемым без этого (в Java 7 он может быть довольно случайным).

Посмотрите на отчет JUnit. JUnit уже организован по пакетам. Каждый пакет имеет (или может иметь) классы TestSuite, каждый из которых, в свою очередь, запускает несколько тестовых случаев. Каждый TestCase может иметь несколько методов тестирования в формеpublic void test*() , каждый из которых фактически станет экземпляром класса TestCase, к которому они принадлежат. Каждый метод тестирования (экземпляр TestCase) имеет имя и критерии прохождения / неудачи.

То, что требует мое руководство, так это концепция индивидуального TestStep элементов , каждый из которых сообщает свои критерии прохождения / неудачи. Сбой любого шага теста не должен препятствовать выполнению последующих шагов теста.

В прошлом разработчики тестов, занимающие мою должность, организовывали классы TestCase в пакеты, соответствующие частям тестируемого продукта, создавали класс TestCase для каждого теста и делали каждый метод тестирования отдельным «шагом» в тесте. дополнить его собственными критериями прохождения / неудачи в выходных данных JUnit. Каждый TestCase является отдельным «тестом», но отдельные методы или «шаги» теста в пределах TestCase должны выполняться в определенном порядке.

Методы TestCase были шагами TestCase, и разработчики тестов получали отдельный критерий прохождения / неудачи для каждого шага теста. Теперь шаги теста перепутаны, и тесты (конечно) не пройдены.

Например:

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()

Каждый метод тестирования утверждает и сообщает свои собственные критерии прохождения / неудачи. Объединение этого в «один большой метод тестирования» для упорядочения теряет гранулярность критериев прохождения / сбоя каждого «шага» в сводном отчете JUnit. ... и это расстраивает моих менеджеров. В настоящее время они требуют другой альтернативы.

Может ли кто-нибудь объяснить, как JUnit с упорядоченным методом проверки теста будет поддерживать отдельные критерии прохождения / отказа каждого последовательного шага тестирования, как показано выше и требуется моим руководством?

Независимо от документации, я вижу в этом серьезную регрессию в среде JUnit, которая усложняет жизнь многим разработчикам тестов.

Обновление JUnit 5 (и мое мнение)

Я думаю, что это очень важная функция для JUnit, если автору JUnit не нужна функция заказа, почему?

По умолчанию библиотеки модульного тестирования не пытаются выполнять тесты в порядке, указанном в исходном файле.
JUnit 5 как JUnit 4 работает таким образом. Почему ? Потому что, если порядок имеет значение, это означает, что некоторые тесты связаны между собой, и это нежелательно для модульных тестов .
Таким образом, @Nestedфункция, представленная JUnit 5, следует тому же подходу по умолчанию.

Но для интеграционных тестов порядок метода тестирования может иметь значение, так как метод тестирования может изменить состояние приложения так, как этого требует другой метод тестирования. Например, когда вы пишете интеграционный тест для обработки заказа в интернет-магазине, первый метод тестирования, который должен быть выполнен, - это регистрация клиента, второй - добавление товаров в корзину, а последний - оформление заказа. Если участник теста не соблюдает этот порядок, сценарий тестирования имеет недостатки и не будет выполнен.
Таким образом, в JUnit 5 (из версии 5.4) у вас все равно есть возможность установить порядок выполнения, пометив тестовый класс с помощью @TestMethodOrder(OrderAnnotation.class)и указав порядок @Order(numericOrderValue)для методов, для которых этот порядок важен.

Например :

@TestMethodOrder(OrderAnnotation.class) 
class FooTest {

    @Order(3)
    @Test
    void checkoutOrder() {
        System.out.println("checkoutOrder");
    }

    @Order(2)
    @Test
    void addItemsInBasket() {
        System.out.println("addItemsInBasket");
    }

    @Order(1)
    @Test
    void createUserAndLogin() {
        System.out.println("createUserAndLogin");
    }
}

Вывод :

createUserAndLogin

addItemsInBasket

checkoutOrder

Кстати, указание @TestMethodOrder(OrderAnnotation.class)выглядит ненужным (по крайней мере, в версии 5.4.0, которую я тестировал).

Заметка по
поводу вопроса: является ли JUnit 5 лучшим выбором для написания интеграционных тестов? Я не думаю, что это должен быть первый инструмент, который следует рассмотреть (Cucumber и co часто могут принести более специфическую ценность и возможности для интеграционных тестов), но в некоторых интеграционных тестах достаточно инфраструктуры JUnit. Так что это хорошая новость, что эта функция существует.

Не уверен, что согласен. Если я хочу проверить «Загрузка файла», а затем проверить «Данные, добавленные при загрузке файла», почему бы мне не захотеть, чтобы они были независимы друг от друга? Я думаю, что вполне разумно запускать их отдельно, а не в обоих тестовых примерах Голиафа.

То, что вы хотите, вполне разумно, когда тесты запускаются как набор.

К сожалению, сейчас нет времени дать полное решение, но взгляните на класс:

org.junit.runners.Suite

Что позволяет вызывать тестовые наборы (из любого тестового класса) в определенном порядке.

Они могут быть использованы для создания функциональных, интеграционных или системных тестов.

В результате ваши модульные тесты остаются без определенного порядка (как рекомендуется), независимо от того, выполняете ли вы их так или нет, а затем повторно используете тесты как часть более широкой картины.

Мы повторно используем / наследуем один и тот же код для модульных, интеграционных и системных тестов, иногда на основе данных, иногда на основе фиксации, а иногда и в качестве пакета.

Смотрите мое решение здесь: "Junit и Java 7."

В этой статье я опишу, как запускать тесты junit по порядку - «как в исходном коде». Тесты будут запущены, чтобы ваши методы тестирования появились в файле класса.

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

Но, как сказал Паскаль Тивент, это не очень хорошая практика.

С помощью JUnit 5.4 вы можете указать порядок:

@Test
@Order(2)
public void sendEmailTestGmail() throws MessagingException {

вам просто нужно аннотировать свой класс

@TestMethodOrder(OrderAnnotation.class)

https://junit.org/junit5/docs/current/user-guide/#writing-tests-test-execution-order

Я использую это в своем проекте, и это работает очень хорошо!

Я прочитал несколько ответов и согласен с тем, что это не лучшая практика, но самый простой способ заказать ваши тесты - и способ, которым JUnit запускает тесты по умолчанию, - это алфавитное имя по возрастанию.

Так что просто назовите ваши тесты в алфавитном порядке, который вы хотите. Также обратите внимание, что название теста должно начинаться со слова test. Просто следите за номерами

test12 будет запущен до test2

так:

testA_MyFirstTest testC_ThirdTest testB_ATestThatRunsSecond

Пожалуйста, проверьте это: https://github.com/TransparentMarket/junit . Он запускает тест в указанном порядке (определенном в скомпилированном файле класса). Также он включает в себя пакет AllTests для запуска тестов, определенных в подпакете. Используя реализацию AllTests, можно расширить решение, также фильтруя свойства (мы использовали аннотации @Fast, но они еще не были опубликованы).

Вот расширение к JUnit, которое может производить желаемое поведение: https://github.com/aafuks/aaf-junit

Я знаю, что это противоречит авторам философии JUnit, но при использовании JUnit в средах, где нет строгого модульного тестирования (как практикуется в Java), это может быть очень полезно.

Я оказался здесь, думая, что мои тесты были выполнены не по порядку, но правда в том, что беспорядок был в моих асинхронных заданиях. При работе с параллелизмом вам необходимо также выполнять проверки параллельности между вашими тестами. В моем случае задания и тесты имеют общий семафор, поэтому следующие тесты зависают до тех пор, пока запущенное задание не снимет блокировку.

Я знаю, что это не полностью связано с этим вопросом, но, возможно, может помочь в определении правильного вопроса.

Вы можете использовать один из этих кусков кода:

@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 { ...}