Як запустити методи тестування у визначеному порядку в 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(){}
}

Це забезпечує етап2 виклики після етапу1 та перед стадією3.

Це одне з головних питань, з якими я стикався, коли працював над Юнітом, і я придумав таке рішення, яке для мене добре працює:

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

Тепер припустимо, що у вас є клас А, де ви написали кілька тестових випадків, як нижче:

(@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 вводить a @SortMethodsWith. https://github.com/junit-team/junit/pull/293 принаймні зробив замовлення передбачуваним без цього (у Java 7 це може бути цілком випадковим).

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

Що вимагає моє управління - це концепція індивідуального тестування елементів , кожен з яких повідомляє про власні критерії проходження / відмови. Відмова будь-якого етапу тесту не повинна перешкоджати виконанню наступних етапів випробувань.

Раніше розробники тестів в моєму положенні організовували заняття 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

замовленняЗамовник

До речі, уточнюючи @TestMethodOrder(OrderAnnotation.class) виглядає не потрібною (принаймні у тестованій 5.4.0 версії).

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

Не впевнений, що я згоден. Якщо я хочу перевірити "Завантаження файлів", а потім перевірити "Дані, вставлені файлом завантаження", чому я не хочу, щоб вони не залежали один від одного? Цілком розумним я вважаю, що зможу запускати їх окремо, а не мати те й інше в тестовому випадку Goliath.

Те, що ви хочете, цілком розумно, коли тестові справи ведуться як комплект.

На жаль, зараз немає часу, щоб дати повне рішення, але подивіться на клас:

org.junit.runners.Suite

Що дозволяє викликати тестові випадки (з будь-якого класу тестів) у визначеному порядку.

Вони можуть бути використані для створення функціональних, інтеграційних або системних тестів.

Це залишає ваші тестові одиниці, оскільки вони є без конкретного порядку (як рекомендується), незалежно від того, запускаєте ви їх так чи ні, а потім повторно використовуєте тести як частину більшої картини.

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

Дивіться моє рішення тут: "Хуніт і ява 7."

У цій статті я описую, як запустити тести на день, щоб - «так само, як у вашому вихідному коді». Тести будуть запускатися для того, щоб ваші методи тестування відображалися у файлі класу

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 виконує тести за замовчуванням, - це алфавітне ім'я у порядку зростання.

Тому просто назвіть свої тести в алфавітному порядку, який вам потрібно. Також зверніть увагу, що назва тесту повинна починатися зі слова тест. Просто стежте за номерами

test12 запуститься до test2

тому:

testA_MyFirstTest testC_ThirdTest тестB_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 { ...}